idnits 2.17.1 draft-gundogan-icnrg-ccnx-timetlv-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IEEE.754.2019]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 January 2022) is 826 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 299 -- Looks like a reference, but probably isn't: '255' on line 299 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG C. Gundogan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: 25 July 2022 D. Oran 6 Network Systems Research and Design 7 M. Waehlisch 8 link-lab & FU Berlin 9 21 January 2022 11 Alternative Delta Time Encoding for CCNx Using Compact Floating-Point 12 Arithmetic 13 draft-gundogan-icnrg-ccnx-timetlv-05 15 Abstract 17 CCNx utilizes delta time for a number of functions. When using CCNx 18 in environments with constrained nodes and/or bandwidth constrained 19 networks, it is valuable to have a compressed representation of delta 20 time. In order to do so, either accuracy or dynamic range has to be 21 sacrificed. Since the current uses of delta time do not require both 22 simultaneously, one can consider a logarithmic encoding such as that 23 specified in [IEEE.754.2019]. This document updates _CCNx messages 24 in TLV Format_ (RFC8609) to specify this alternative encoding. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 25 July 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Usage of Time Values in CCNx . . . . . . . . . . . . . . . . 3 62 3.1. Relative Time in CCNx . . . . . . . . . . . . . . . . . . 3 63 3.2. Absolute Time in CCNx . . . . . . . . . . . . . . . . . . 3 64 4. A Compact Time Representation with Logarithmic Range . . . . 4 65 5. Protocol Integration of the Compact Time Representation . . . 6 66 5.1. Interest Lifetime . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Recommended Cache Time . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 9 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 CCNx utilizes time values for a number of functions. Some of these 80 are expressed as absolute time, others as delta time. When using 81 CCNx in environments with constrained nodes and/or bandwidth 82 constrained networks, it is valuable to have a compact representation 83 of time values. For example [RFC9139] specifies a compression scheme 84 useful over IEEE 802.15.4 networks. However, any compact time 85 representation has to sacrifice either accuracy or dynamic range or 86 both. For some time uses this is relatively straightforward to 87 achieve, for other uses, it is not. This document discusses the 88 various cases, and proposes a compact encoding that is easily 89 accommodated for delta times. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 This document uses the terminology of [RFC8569] and [RFC8609] for 98 CCNx entities. 100 The following terms are used in the document and defined as follows: 102 byte: synonym for octet 104 time value: a time offset measured in seconds 106 time code: an 8-bit encoded time value 108 3. Usage of Time Values in CCNx 110 3.1. Relative Time in CCNx 112 CCNx, as currently specified in [RFC8569], utilizes delta time for 113 only the lifetime of an Interest message (see sections 2.1, 2.2, 114 2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is 115 currently encoded via the T_INTLIFE TLV as a 64-bit integer 116 ([RFC8609] section 3.4.1). While formally an optional TLV, in all 117 but some corner cases every Interest message is expected to carry the 118 Interest Lifetime TLV, and hence having compact encoding is 119 particularly valuable for keeping Interest messages short. 121 Since the current uses of delta time do not require both accuracy and 122 dynamic range simultaneously, one can consider a logarithmic encoding 123 such as that specified in [IEEE.754.2019] and outlined in Section 4. 124 This document updates CCNx messages in TLV Format ([RFC8609]) to 125 permit this alternative encoding for selected time values. See 126 Section 6 for the specific actions needed to register this 127 alternative compact representation of Interest Lifetime. 129 3.2. Absolute Time in CCNx 131 CCNx, as currently specified in [RFC8569], utilizes absolute time for 132 various important functions. Each of these absolute time usages 133 poses a different challenge for a compact representation. These are 134 discussed in the following subsections. 136 3.2.1. Signature Time and Expiry Time 138 _Signature Time_ is the time the signature of a content object was 139 generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the 140 expiry time of a content object (section 4 [RFC8569]). Both values 141 are content message TLVs and represent absolute timestamps in 142 milliseconds since the UTC epoch (i.e., an NTP timestamp). They are 143 currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit 144 unsigned integers (see section 3.6.4.1.4.5 [RFC8609] and section 145 3.6.2.2.2 [RFC8609]). 147 Both time values could be in the past, or in the future, potentially 148 by a large delta. They are also included in the security envelope of 149 the message. Therefore, it seems there is no practical way to define 150 an alternative compact encoding that preserves its semantics and 151 security properties; hence we don't consider it further as a 152 candidate. 154 3.2.2. Recommended Cache Time 156 _Recommended Cache Time_ (RCT) for a content object (see section 4 157 [RFC8569]) is a hop-by-hop header stating the expiration time for a 158 cached content object in milliseconds since the UTC epoch (i.e., an 159 NTP timestamp). It is currently encoded via the T_CACHETIME TLV as a 160 64-bit unsigned integer (see section 3.4.2 [RFC8609]). 162 A recommended cache time could be far in the future, but cannot be in 163 the past and is likely to be a reasonably short offset from the 164 current time. Therefore, this document allows the recommended cache 165 time to be interpreted as a relative time value rather than an 166 absolute time, since the semantics associated with an absolute time 167 value do not seem to be critical to the utility of this value. This 168 document therefore updates the recommended cache time with the 169 following rule set: 171 * Use absolute time as per [RFC8609] 173 * Use relative time, if the compact time representation is used (see 174 Section 4 and Section 5) 176 4. A Compact Time Representation with Logarithmic Range 178 This document uses the compact time representation of ICNLoWPAN (see 179 section 7 of [RFC9139]) that is inspired by [RFC5497] and 180 [IEEE.754.2019]. Its logarithmic encoding supports a representation 181 ranging from milliseconds to years. Figure 1 depicts the logarithmic 182 nature of this time representation. 184 || | | | | | | | | | | 185 +-----------------------------------------------------------------+ 186 milliseconds years 188 Figure 1: A logarithmic range representation allows for higher 189 precision in the smaller time ranges and still supports large 190 time deltas. 192 Time codes encode exponent and mantissa values in a single byte, but 193 in contrast to the representation in [IEEE.754.2019], time codes only 194 encode positive numbers and hence do not include an extra sign bit. 195 Figure 2 shows the configuration of a time code: an exponent width of 196 5 bits, and a mantissa width of 3 bits. 198 <--- one byte wide ---> 199 +----+----+----+----+----+----+----+----+ 200 | exponent (b) | mantissa (a) | 201 +----+----+----+----+----+----+----+----+ 202 0 1 2 3 4 5 6 7 204 Figure 2: A time code with exponent and mantissa to encode a 205 logarithmic range time representation. 207 The base unit for time values are seconds. A time value is 208 calculated using the following formula (adopted from [RFC5497] and 209 [RFC9139]), where (a) represents the mantissa, (b) the exponent, and 210 (C) a constant factor set to C := 1/32. 212 Subnormal (b == 0): (0 + a/8) * 2 * C 214 Normalized (b > 0): (1 + a/8) * 2^b * C 216 The subnormal form provides a gradual underflow between zero and the 217 smallest normalized number. Eight time values exist in the subnormal 218 range [0s,~0.054688s] with a step size of ~0.007812s between each 219 time value. This configuration also encodes the following convenient 220 numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. Appendix A 221 further includes test vectors to illustrate the logarithmic range. 223 An example algorithm to encode a time value into the corresponding 224 exponent and mantissa is given as pseudo code in Figure 3. Not all 225 time values can be represented by a time code. For these instances, 226 the closest time code is chosen that is smaller than the value to 227 encode. 229 input: float v // time value 230 output: int a, b // mantissa, exponent of time code 232 (a, b) encode (v): 234 if (v == 0) 235 return (0, 0) 237 if (v < 2 * C) // subnormal 238 a = floor (v * 4 / C) // round down 239 return (a, 0) 240 else // normalized 241 if (v > (1 + 7/8) * 2^31 * C) // check bounds 242 return (7, 31) // return maximum 243 else 244 b = floor (log2(v / C)) // round down 245 a = floor ((v / (2^b * C) - 1) * 8) // round down 246 return (a, b) 248 Figure 3: Algorithm in pseudo code. 250 As an example: No specific time code for 0.063 exists, but this 251 algorithm maps to the closest valid time code that is smaller, i.e., 252 exponent 1 and mantissa 0 (the same as for time value 0.0625). 254 5. Protocol Integration of the Compact Time Representation 256 A straightforward way to accommodate the compact time approach is to 257 use a 1-byte length field to indicate this alternative encoding while 258 retaining the existing TLV registry entries. This approach has 259 backward compatibility problems, but may still be considered for the 260 following reasons: 262 * Both CCNx RFCs are experimental and not Standards Track, hence 263 expectations for forward and backward compatibility are not as 264 stringent. "Flag day" upgrades of deployed CCNx networks, while 265 inconvenient, are still feasible. 267 * The major use case for these compressed encodings are smaller- 268 scale IoT and/or sensor networks where the population of 269 consumers, producers, and forwarders is reasonably small. 271 * Since the current TLVs have hop-by-hop semantics, they are not 272 covered by any signed hash and hence may be freely re-encoded by 273 any forwarder. That means a forwarder supporting the new encoding 274 can translate freely between the two encodings. 276 * The alternative of assigning new TLV registry values does not 277 substantially mitigate the interoperability problems anyway. 279 The following lists alternative approaches of integrating the compact 280 time representation for time offsets in CCNx messages. A further 281 analysis, discussion, and decision on the best suited approach will 282 be added as the document progresses. 284 1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to 285 hint at the used encoding. This approach is the least intrusive 286 integration, but adds a TLV overhead that negates the benefits of 287 the compact time representation. 289 2. A new TLV type for T_INTLIFETIME with a compact time 290 representation (T_INTLIFETIME_COMPACT) is defined. The packet 291 header grammar from [RFC8609] is updated to allow for 292 T_INTLIFETIME_COMPACT at the same level of the currently defined 293 T_INTLIFETIME with an exclusive or. 295 5.1. Interest Lifetime 297 The Interest Lifetime definition in [RFC8609] allows for a variable- 298 length lifetime representation, where a length of 1 encodes the 299 linear range [0,255] in milliseconds. This document changes the 300 definition to always encode 1-byte Interest lifetime values in the 301 compact time value representation (Figure 4). 303 1 2 3 304 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 305 +---------------+---------------+---------------+---------------+ 306 | T_INTLIFE | Length > 1 | 307 +---------------+---------------+---------------+---------------+ 308 / / 309 / Lifetime (Length octets) / 310 / / 311 +---------------+---------------+---------------+---------------+ 313 1 2 3 314 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 315 +---------------+---------------+---------------+---------------+ 316 | T_INTLIFE | Length = 1 | 317 +---------------+---------------+---------------+---------------+ 318 | COMPACT_TIME | 319 +---------------+ 321 Figure 4: Changes to the definition of the Interest Lifetime TLV. 323 5.2. Recommended Cache Time 325 The Recommended Cache Time definition in [RFC8609] specifies an 326 absolute time representation that is of a length fixed to 8 bytes. 327 This document changes the definition to always encode 1-byte 328 Recommended Cache Time values in the compact relative time value 329 representation (Figure 5). 331 1 2 3 332 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 333 +---------------+---------------+---------------+---------------+ 334 | T_CACHETIME | Length = 8 | 335 +---------------+---------------+---------------+---------------+ 336 / / 337 / Recommended Cache Time / 338 / / 339 +---------------+---------------+---------------+---------------+ 340 1 2 3 341 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 342 +---------------+---------------+---------------+---------------+ 343 | T_CACHETIME | Length = 1 | 344 +---------------+---------------+---------------+---------------+ 345 | COMPACT_TIME | 346 +---------------+ 348 Figure 5: Changes to the definition of the Recommended Cache Time 349 TLV. 351 The packet processing is adapted to calculate an absolute time from 352 the relative time code based on the absolute reception time. On 353 transmission, a new relative time code is calculated based on the 354 current system time. 356 6. IANA Considerations 358 Based on the approach of integration, certain TLV registries from 359 [RFC8609] need to be updated. 361 7. Security Considerations 363 This document makes no semantic changes to [RFC8569], nor to any of 364 the security properties of the message encodings of [RFC8609], and 365 hence has the same security considerations as those two existing 366 documents. 368 8. References 370 8.1. Normative References 372 [IEEE.754.2019] 373 Institute of Electrical and Electronics Engineers, C/MSC - 374 Microprocessor Standards Committee, "Standard for 375 Floating-Point Arithmetic", June 2019, 376 . 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 385 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 386 DOI 10.17487/RFC5497, March 2009, 387 . 389 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 390 Networking (CCNx) Semantics", RFC 8569, 391 DOI 10.17487/RFC8569, July 2019, 392 . 394 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 395 Networking (CCNx) Messages in TLV Format", RFC 8609, 396 DOI 10.17487/RFC8609, July 2019, 397 . 399 8.2. Informative References 401 [RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C., 402 Marxer, C., and C. Tschudin, "Information-Centric 403 Networking (ICN) Adaptation to Low-Power Wireless Personal 404 Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, 405 November 2021, . 407 Appendix A. Test Vectors 409 The test vectors in Table 1 show sample time codes and their 410 corresponding time values according to the algorithm outlined in 411 Section 4. 413 +===========+======================+ 414 | Time Code | Time Value (seconds) | 415 +===========+======================+ 416 | 0x00 | 0.000000 | 417 +-----------+----------------------+ 418 | 0x01 | 0.007812 | 419 +-----------+----------------------+ 420 | 0x04 | 0.031250 | 421 +-----------+----------------------+ 422 | 0x08 | 0.062500 | 423 +-----------+----------------------+ 424 | 0x15 | 0.203125 | 425 +-----------+----------------------+ 426 | 0x28 | 1.000000 | 427 +-----------+----------------------+ 428 | 0x30 | 2.000000 | 429 +-----------+----------------------+ 430 | 0xF8 | 67108864.000000 | 431 +-----------+----------------------+ 432 | 0xFF | 125829120.000000 | 433 +-----------+----------------------+ 435 Table 1: Test Vectors 437 Acknowledgments 439 We would like to thank the active members of the ICNRG research group 440 for constructive thoughts. In particular, we thank Marc Mosko for 441 his feedback on the encoding scheme, the provided pseudo code, and 442 test vectors. 444 Authors' Addresses 446 Cenk Gundogan 447 HAW Hamburg 448 Berliner Tor 7 449 D-20099 Hamburg 450 Germany 452 Phone: +4940428758067 453 Email: cenk.guendogan@haw-hamburg.de 454 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 455 Thomas C. Schmidt 456 HAW Hamburg 457 Berliner Tor 7 458 D-20099 Hamburg 459 Germany 461 Email: t.schmidt@haw-hamburg.de 462 URI: http://inet.haw-hamburg.de/members/schmidt 464 Dave Oran 465 Network Systems Research and Design 466 4 Shady Hill Square 467 Cambridge, MA 02138 468 United States of America 470 Email: daveoran@orandom.net 472 Matthias Waehlisch 473 link-lab & FU Berlin 474 Hoenower Str. 35 475 D-10318 Berlin 476 Germany 478 Email: mw@link-lab.net 479 URI: http://www.inf.fu-berlin.de/~waehl