summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9510.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9510.txt')
-rw-r--r--doc/rfc/rfc9510.txt530
1 files changed, 530 insertions, 0 deletions
diff --git a/doc/rfc/rfc9510.txt b/doc/rfc/rfc9510.txt
new file mode 100644
index 0000000..a280752
--- /dev/null
+++ b/doc/rfc/rfc9510.txt
@@ -0,0 +1,530 @@
+
+
+
+
+Internet Research Task Force (IRTF) C. Gündoğan
+Request for Comments: 9510 Huawei
+Updates: 8609 TC. Schmidt
+Category: Experimental HAW Hamburg
+ISSN: 2070-1721 D. Oran
+ Network Systems Research and Design
+ M. Wählisch
+ TU Dresden
+ February 2024
+
+
+ Alternative Delta Time Encoding for Content-Centric Networking (CCNx)
+ Using Compact Floating-Point Arithmetic
+
+Abstract
+
+ 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.
+
+ This document is a product of the IRTF Information-Centric Networking
+ Research Group (ICNRG).
+
+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
+ 2. Terminology
+ 3. Usage of Time Values in CCNx
+ 3.1. Relative Time in CCNx
+ 3.2. Absolute Time in CCNx
+ 4. A Compact Time Representation with Logarithmic Range
+ 5. Protocol Integration of the Compact Time Representation
+ 5.1. Interest Lifetime
+ 5.2. Recommended Cache Time
+ 6. IANA Considerations
+ 7. Security Considerations
+ 8. References
+ 8.1. Normative References
+ 8.2. Informative References
+ Appendix A. Test Vectors
+ Appendix B. Efficient Time Value Approximation
+ Acknowledgments
+ Authors' Addresses
+
+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.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+ This document uses the terminology of [RFC8569] and [RFC8609] for
+ CCNx entities.
+
+ The following terms are used in the document and defined as follows:
+
+ byte: synonym for octet
+
+ time value: a time offset measured in seconds
+
+ time code: an 8-bit encoded time value as defined in [RFC5497]
+
+3. Usage of Time Values in CCNx
+
+3.1. Relative Time in CCNx
+
+ CCNx, as currently specified in [RFC8569], utilizes delta time for
+ only the lifetime of an Interest message (see Sections 2.1, 2.2,
+ 2.4.2, and 10.3 of [RFC8569]). It is a hop-by-hop header value, and
+ is currently encoded via the T_INTLIFE TLV as a 64-bit integer
+ (Section 3.4.1 of [RFC8609]). While formally an optional TLV, every
+ Interest message is expected to carry the Interest Lifetime TLV in
+ all but some corner cases; hence, having compact encoding is
+ particularly valuable to keep Interest messages short.
+
+ 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 [IEEE.754.2019] and as outlined in
+ Section 4. This document updates CCNx messages in TLV format
+ [RFC8609] to permit this alternative encoding for selected time
+ values.
+
+3.2. Absolute Time in CCNx
+
+ CCNx, as currently specified in [RFC8569], 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.
+
+3.2.1. Signature Time and Expiry Time
+
+ Signature Time is the time the signature of a Content Object was
+ generated (see Sections 8.2-8.4 of [RFC8569]). Expiry Time indicates
+ the time after which a Content Object is considered expired
+ (Section 4 of [RFC8569]). 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 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
+ 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; therefore, this approach is not considered
+ further.
+
+3.2.2. Recommended Cache Time
+
+ Recommended Cache Time (RCT) for a Content Object (Section 4 of
+ [RFC8569]) is a hop-by-hop header stating the expiration time for a
+ cached Content Object in milliseconds since the POSIX epoch. It is
+ currently encoded via the T_CACHETIME TLV as a 64-bit unsigned
+ integer (see Section 3.4.2 of [RFC8609]).
+
+ 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 time. Therefore, this document allows the Recommended Cache
+ Time to be interpreted as a relative time value rather than an
+ absolute time, because the semantics associated 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:
+
+ * Use absolute time as per [RFC8609]
+
+ * Use relative time, if the compact time representation is used (see
+ Sections 4 and 5)
+
+ 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. Thus, the
+ Recommended Cache Time cannot be as accurate as when absolute time is
+ used. 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 and seconds for the
+ Recommended Cache Time is still tolerable in these networks and does
+ not impact the protocol performance.
+
+ 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.
+
+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
+
+ Figure 1: A logarithmic range representation allows for higher
+ precision in the smaller time ranges and still supports large
+ time deltas.
+
+ 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
+
+ Figure 2: A time code with exponent and mantissa to encode a
+ logarithmic range time representation.
+
+ 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)
+
+ Figure 3: Algorithm in pseudocode.
+
+ 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.
+
+5.1. Interest Lifetime
+
+ The Interest Lifetime definition in [RFC8609] allows for a variable-
+ length lifetime representation, where a length of 1 encodes the
+ linear range [0,255] in milliseconds. This document changes the
+ definition to always encode 1-byte Interest Lifetime values in the
+ 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
+ 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 |
+ +---------------+
+
+ Figure 4: Changes to the definition of the Interest Lifetime TLV.
+
+5.2. Recommended Cache Time
+
+ The Recommended Cache Time definition in [RFC8609] 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 (see Figure 5). For any other length, Recommended
+ Cache Times are encoded as described in Section 3.4.2 of [RFC8609].
+
+ 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 |
+ +---------------+
+
+ Figure 5: Changes to the definition of the Recommended Cache Time
+ TLV.
+
+ 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.
+
+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.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
+ Networking (CCNx) Semantics", RFC 8569,
+ DOI 10.17487/RFC8569, July 2019,
+ <https://www.rfc-editor.org/info/rfc8569>.
+
+ [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
+ Networking (CCNx) Messages in TLV Format", RFC 8609,
+ DOI 10.17487/RFC8609, July 2019,
+ <https://www.rfc-editor.org/info/rfc8609>.
+
+8.2. Informative References
+
+ [ICNLOWPAN]
+ Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch,
+ "Designing a LoWPAN convergence layer for the Information
+ Centric Internet of Things", Computer Communications, Vol.
+ 164, No. 1, p. 114-123, Elsevier, December 2020,
+ <https://doi.org/10.1016/j.comcom.2020.10.002>.
+
+ [IEEE.754.2019]
+ IEEE, "Standard for Floating-Point Arithmetic", IEEE
+ Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019,
+ <https://standards.ieee.org/content/ieee-standards/en/
+ standard/754-2019.html>.
+
+ [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
+ Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
+ DOI 10.17487/RFC5497, March 2009,
+ <https://www.rfc-editor.org/info/rfc5497>.
+
+ [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
+ Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
+ "Information-Centric Networking (ICN) Research
+ Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
+ <https://www.rfc-editor.org/info/rfc7927>.
+
+ [RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C.,
+ Marxer, C., and C. Tschudin, "Information-Centric
+ Networking (ICN) Adaptation to Low-Power Wireless Personal
+ Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139,
+ November 2021, <https://www.rfc-editor.org/info/rfc9139>.
+
+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.
+
+ +===========+======================+
+ | Time Code | Time Value (seconds) |
+ +===========+======================+
+ | 0x00 | 0.0000000 |
+ +-----------+----------------------+
+ | 0x01 | 0.0078125 |
+ +-----------+----------------------+
+ | 0x04 | 0.0312500 |
+ +-----------+----------------------+
+ | 0x08 | 0.0625000 |
+ +-----------+----------------------+
+ | 0x15 | 0.2031250 |
+ +-----------+----------------------+
+ | 0x28 | 1.0000000 |
+ +-----------+----------------------+
+ | 0x30 | 2.0000000 |
+ +-----------+----------------------+
+ | 0xF8 | 67108864.0000000 |
+ +-----------+----------------------+
+ | 0xFF | 125829120.0000000 |
+ +-----------+----------------------+
+
+ Table 1: Test Vectors
+
+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
+
+ Cenk Gündoğan
+ Huawei Technologies Duesseldorf GmbH
+ Riesstrasse 25
+ D-80992 Munich
+ Germany
+ Email: cenk.gundogan@huawei.com
+
+
+ Thomas C. Schmidt
+ HAW Hamburg
+ Berliner Tor 7
+ D-20099 Hamburg
+ Germany
+ Email: t.schmidt@haw-hamburg.de
+ URI: http://inet.haw-hamburg.de/members/schmidt
+
+
+ Dave Oran
+ Network Systems Research and Design
+ 4 Shady Hill Square
+ Cambridge, MA 02138
+ United States of America
+ Email: daveoran@orandom.net
+
+
+ Matthias Wählisch
+ TUD Dresden University of Technology
+ Helmholtzstr. 10
+ D-01069 Dresden
+ Germany
+ Email: m.waehlisch@tu-dresden.de