idnits 2.17.1 draft-gundogan-icnrg-ccnx-timetlv-03.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: ---------------------------------------------------------------------------- No issues found here. 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 (18 January 2021) is 1194 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 211 -- Looks like a reference, but probably isn't: '31' on line 210 -- Looks like a reference, but probably isn't: '7' on line 211 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icnlowpan-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: 22 July 2021 D. Oran 6 Network Systems Research and Design 7 M. Waehlisch 8 link-lab & FU Berlin 9 18 January 2021 11 Alternative Delta Time Encoding for CCNx Using Compact Floating-Point 12 Arithmetic 13 draft-gundogan-icnrg-ccnx-timetlv-03 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 22 July 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 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 3.2.1. Signature Time and Expiry Time . . . . . . . . . . . 3 65 3.2.2. Recommended Cache Time . . . . . . . . . . . . . . . 4 66 4. A Compact Time Representation with Logarithmic Range . . . . 4 67 5. Protocol Integration of the Compact Time Representation in CCNx 68 Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 [I-D.irtf-icnrg-icnlowpan] specifies a 84 compression scheme useful over IEEE 802.15.4 networks. However, any 85 compact time representation has to sacrifice either accuracy or 86 dynamic range or both. For some time uses this is relatively 87 straightforward to achieve, for other uses, it is not. This document 88 discusses the various cases, and proposes a compact encoding that is 89 easily accommodated for delta times, and a more complicated method 90 that can be considered for some uses of absolute time. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Usage of Time Values in CCNx 100 3.1. Relative Time in CCNx 102 CCNx, as currently specified in [RFC8569], utilizes delta time for 103 only the lifetime of an Interest message (see sections 2.1, 2.2, 104 2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is 105 currently encoded via the T_INTLIFE TLV as a 64-bit integer 106 ([RFC8609] section 3.4.1). While formally an optional TLV, in all 107 but some corner cases every Interest message is expected to carry the 108 Interest Lifetime TLV, and hence having compact encoding is 109 particularly valuable for keeping Interest messages short. 111 Since the current uses of delta time do not require both accuracy and 112 dynamic range simultaneously, one can consider a logarithmic encoding 113 such as that specified in [IEEE.754.2019] and outlined in Section 4. 114 This document updates CCNx messages in TLV Format ([RFC8609]) to 115 permit this alternative encoding for selected time values. See 116 Section 6 for the specific actions needed to register this 117 alternative compact representation of Interest Lifetime. 119 3.2. Absolute Time in CCNx 121 CCNx, as currently specified in [RFC8569], utilizes absolute time for 122 various important functions. Each of these absolute time usages 123 poses a different challenge for a compact representation. These are 124 discussed in the following subsections. 126 3.2.1. Signature Time and Expiry Time 128 _Signature Time_ is the time the signature of a content object was 129 generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the 130 expiry time of a content object (section 4 [RFC8569]). Both values 131 are content message TLVs and represent absolute timestamps in 132 milliseconds since the UTC epoch (i.e., an NTP timestamp). They are 133 currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit 134 unsigned integers (see section 3.6.4.1.4.5 [RFC8609] and section 135 3.6.2.2.2 [RFC8609]). 137 Both time values could be in the past, or in the future, potentially 138 by a large delta. They are also included in the security envelope of 139 the message. Therefore, it seems there is no practical way to define 140 an alternative compact encoding that preserves its semantics and 141 security properties; hence we don't consider it further as a 142 candidate. 144 3.2.2. Recommended Cache Time 146 _Recommended Cache Time_ (RCT) for a content object (see section 4 147 [RFC8569]) is a hop-by-hop header stating the expiration time for a 148 cached content object in milliseconds since the UTC epoch (i.e., an 149 NTP timestamp). It is currently encoded via the T_CACHETIME TLV as a 150 64-bit unsigned integer (see section 3.4.2 [RFC8609]). 152 A recommended cache time could be far in the future, but cannot be in 153 the past and is likely to be a reasonably short offset from the 154 current time. Therefore, this document allows the recommended cache 155 time to be interpreted as a relative time value rather than an 156 absolute time, since the semantics associated with an absolute time 157 value do not seem to be critical to the utility of this value. This 158 document therefore updates the recommended cache time with the 159 following rule set: 161 * Use absolute time as per [RFC8609] 163 * Use relative time, if the compact time representation is used (see 164 Section 4 and Section 5) 166 4. A Compact Time Representation with Logarithmic Range 168 This document defines a compact time representation with logarithmic 169 range support that is inspired by [RFC5497] and [IEEE.754.2019]. 170 Compact time codes are one octet wide and represent time values that 171 range from milliseconds to years. Figure 1 depicts the logarithmic 172 nature of this time representation. 174 || | | | | | | | | | | 175 +-----------------------------------------------------------------+ 176 milliseconds years 178 Figure 1: A logarithmic range representation allows for higher 179 precision in the smaller time ranges and still supports large 180 time deltas. 182 Time codes encode an exponent and a mantissa as illustrated in 183 Figure 2. In contrast to the representation in [IEEE.754.2019], time 184 codes only encode positive numbers and hence do not include an extra 185 sign bit. 187 <--- one octet wide ---> 188 +---+---+---+---+---+---+---+---+ 189 | exponent (e) | mantissa (m) | 190 +---+---+---+---+---+---+---+---+ 192 Figure 2: A time code with exponent and mantissa to encode a 193 logarithmic range time representation. 195 The base unit for time values are seconds. A time value is 196 calculated using the following formula, where (e) represents the 197 exponent, (m) the mantissa, (m_max) the maximum mantissa value, and 198 (b) the bias. 200 Subnormal (e == 0): (0 + m/m_max) * 2^(1+b) 202 Normalized (e > 0): (1 + m/m_max) * 2^(e+b) 204 The subnormal form is only applied when the exponent is zero. This 205 form provides a gradual underflow for the gap between the smallest 206 normalized number and zero. The normalized form is applied for all 207 values with an exponent greater than zero. 209 This document allocates "5" bits for the exponent and "3" bits for 210 the mantissa. Therefore, exponents have the range [0,31] and 211 mantissae have the range [0,7]. This document further applies a bias 212 of "-5". The following properties result from this configuration: 214 * Minimum subnormal number: 0 seconds 216 * Maximum subnormal number: ~0.054688 seconds 218 * Minimum normalized number: ~0.062500 seconds 220 * Maximum normalized number: ~3.99 years 222 Eight time values exist in the subnormal range [0,~0.054688s] with a 223 step size of ~0.007813s between each time value. In addition, this 224 configuration also encodes the following convenient numbers in 225 seconds: [1, 2, 4, 8, 16, 32, 64, ...]. 227 An example algorithm to encode a time value into the corresponding 228 exponent and mantissa is given as pseudo code in Figure 3. Not all 229 time values can be represented by a time code. For these instances, 230 the closest time code is chosen that is smaller than the value to 231 encode. 233 input: float v // time value 234 output: int e, m // exponent, mantissa of time code 236 (e, m) encode (v): 238 if (v == 0) 239 return (0, 0) 241 if (v < 0.0625) 242 m = floor ((v * 2^7)) // round down 243 return (0, m) 244 else 245 e = floor (log2(v)) // round down 246 m = floor (((v / 2^e - 1) * 8)) // round down 247 return (e + 5, m) // add bias 249 Figure 3: Algorithm in pseudo code. 251 As an example: No specific time code for "0.063" exists, but this 252 algorithm maps to the closest valid time code that is smaller, i.e., 253 exponent "1" and mantissa "0" (the same as for time value "0.0625"). 255 5. Protocol Integration of the Compact Time Representation in CCNx 256 Messages 258 A straightforward way to accommodate the compact time approach as an 259 alternative encoding is to simply allow a 1-byte length as an 260 alternative to the 8-byte length while retaining the existing TLV 261 registry entries. This approach has backward compatibility problems, 262 but may still be considered for the following reasons: 264 * Both CCNx RFCs are experimental and not Standards Track, hence 265 expectations for forward and backward compatibility are not as 266 stringent. "Flag day" upgrades of deployed CCNx networks, while 267 inconvenient, are still feasible. 269 * The major use case for these compressed encodings are smaller- 270 scale IoT and/or sensor networks where the population of 271 consumers, producers, and forwarders is reasonably small. 273 * Since the current TLVs have hop-by-hop semantics, they are not 274 covered by any signed hash and hence may be freely re-encoded by 275 any forwarder. That means a forwarder supporting the new encoding 276 can translate freely between the two encodings. 278 * The alternative of assigning new TLV registry values does not 279 substantially mitigate the interoperability problems anyway. 281 The following lists alternative approaches of integrating the compact 282 time representation for time offsets in CCNx messages. A further 283 analysis, discussion, and decision on the best suited approach will 284 be added as the document progresses. 286 1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to 287 hint at the used encoding. This approach is the least intrusive 288 integration, but adds a TLV overhead that negates the benefits of 289 the compact time representation. 291 2. A new TLV type for T_INTLIFETIME with a compact time 292 representation (T_INTLIFETIME_COMPACT) is defined. The packet 293 header grammar from [RFC8609] is updated to allow for 294 T_INTLIFETIME_COMPACT at the same level of the currently defined 295 T_INTLIFETIME with an exclusive or. 297 6. IANA Considerations 299 Based on the approach of integration, certain TLV registries from 300 [RFC8609] need to be updated. 302 7. Security Considerations 304 This document makes no semantic changes to [RFC8569], nor to any of 305 the security properties of the message encodings of [RFC8609], and 306 hence has the same security considerations as those two existing 307 documents. 309 8. References 311 8.1. Normative References 313 [IEEE.754.2019] 314 Institute of Electrical and Electronics Engineers, C/MSC - 315 Microprocessor Standards Committee, "Standard for 316 Floating-Point Arithmetic", June 2019, 317 . 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 326 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 327 DOI 10.17487/RFC5497, March 2009, 328 . 330 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 331 Networking (CCNx) Semantics", RFC 8569, 332 DOI 10.17487/RFC8569, July 2019, 333 . 335 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 336 Networking (CCNx) Messages in TLV Format", RFC 8609, 337 DOI 10.17487/RFC8609, July 2019, 338 . 340 8.2. Informative References 342 [I-D.irtf-icnrg-icnlowpan] 343 Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., 344 Marxer, C., and C. Tschudin, "ICN Adaptation to LoWPAN 345 Networks (ICN LoWPAN)", Work in Progress, Internet-Draft, 346 draft-irtf-icnrg-icnlowpan-09, 30 October 2020, 347 . 350 Appendix A. Test Vectors 352 The test vectors in Table 1 show sample time codes and their 353 corresponding time values according to the algorithm outlined in 354 Section 4. 356 +===========+======================+ 357 | Time Code | Time Value (seconds) | 358 +===========+======================+ 359 | 0x00 | 0.000000 | 360 +-----------+----------------------+ 361 | 0x04 | 0.031250 | 362 +-----------+----------------------+ 363 | 0x08 | 0.062500 | 364 +-----------+----------------------+ 365 | 0x15 | 0.203125 | 366 +-----------+----------------------+ 367 | 0x28 | 1.000000 | 368 +-----------+----------------------+ 369 | 0x30 | 2.000000 | 370 +-----------+----------------------+ 371 | 0xF8 | 67108864.000000 | 372 +-----------+----------------------+ 373 | 0xFF | 125829120.000000 | 374 +-----------+----------------------+ 376 Table 1: Test Vectors 378 Authors' Addresses 380 Cenk Gundogan 381 HAW Hamburg 382 Berliner Tor 7 383 D-20099 Hamburg 384 Germany 386 Phone: +4940428758067 387 Email: cenk.guendogan@haw-hamburg.de 388 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 390 Thomas C. Schmidt 391 HAW Hamburg 392 Berliner Tor 7 393 D-20099 Hamburg 394 Germany 396 Email: t.schmidt@haw-hamburg.de 397 URI: http://inet.haw-hamburg.de/members/schmidt 399 Dave Oran 400 Network Systems Research and Design 401 4 Shady Hill Square 402 Cambridge, MA 02138 403 United States of America 405 Email: daveoran@orandom.net 407 Matthias Waehlisch 408 link-lab & FU Berlin 409 Hoenower Str. 35 410 D-10318 Berlin 411 Germany 413 Email: mw@link-lab.net 414 URI: http://www.inf.fu-berlin.de/~waehl