From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9510.txt | 530 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 530 insertions(+) create mode 100644 doc/rfc/rfc9510.txt (limited to 'doc/rfc/rfc9510.txt') 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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Semantics", RFC 8569, + DOI 10.17487/RFC8569, July 2019, + . + + [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric + Networking (CCNx) Messages in TLV Format", RFC 8609, + DOI 10.17487/RFC8609, July 2019, + . + +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, + . + + [IEEE.754.2019] + IEEE, "Standard for Floating-Point Arithmetic", IEEE + Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019, + . + + [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value + Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, + DOI 10.17487/RFC5497, March 2009, + . + + [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, + . + + [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, . + +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 -- cgit v1.2.3