idnits 2.17.1 draft-gundogan-icnrg-ccnx-timetlv-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 9, 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 225 -- Looks like a reference, but probably isn't: '31' on line 224 -- Looks like a reference, but probably isn't: '7' on line 225 == Outdated reference: A later version (-11) exists of draft-irtf-icnrg-icnlowpan-06 Summary: 0 errors (**), 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: September 10, 2020 D. Oran 6 Network Systems Research and Design 7 M. Waehlisch 8 link-lab & FU Berlin 9 March 9, 2020 11 An Alternative Delta Time encoding for CCNx using Interval Time from 12 RFC5497 13 draft-gundogan-icnrg-ccnx-timetlv-01 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 RFC5497. This document updates _CCNx messages in TLV 24 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 September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Usage of Time values CCNx . . . . . . . . . . . . . . . . . . 3 63 3.1. Relative Time usage in CCNx . . . . . . . . . . . . . . . 3 64 3.2. Absolute Time usage in CCNx . . . . . . . . . . . . . . . 3 65 3.2.1. Signature Time . . . . . . . . . . . . . . . . . . . 3 66 3.2.2. Expiry Time . . . . . . . . . . . . . . . . . . . . . 4 67 3.2.3. Recommended Cache Time . . . . . . . . . . . . . . . 4 68 4. A Compact Time Representation with Logarithmic Range . . . . 4 69 5. Protocol Integration of the Compact Time Representation in 70 CCNx Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 CCNx utilizes Time values for a number of functions. Some of these 81 are expressed as absolute time, others as delta time. When using 82 CCNx in environments with constrained nodes and/or bandwidth 83 constrained networks, it is valuable to have a compact representation 84 of time values. For example [I-D.irtf-icnrg-icnlowpan] specifies a 85 compression scheme useful over IEEE 802.15.4 networks. However, any 86 compact time representation has to sacrifice either accuracy or 87 dynamic range or both. For some time uses this is relatively 88 straightforward to achieve, for other uses, it is not. This document 89 discusses the various cases, and proposes a compact encoding that is 90 easily accommodated for delta times, and a more complicated method 91 that can be considered for some uses of absolute time. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Usage of Time values CCNx 101 3.1. Relative Time usage in CCNx 103 CCNx, as currently specified in [RFC8569], utilizes delta time for 104 only the lifetime of an Interest message (sections 2.1, 2.2, 2.4.2, 105 10.3). It is a hop-by-hop header value, and is currently encoded via 106 the T_INTLIFE TLV as a 64-bit integer ([RFC8609] section 3.4.1). 107 While formally an optional TLV, in all but some corner cases every 108 Interest Message is expected to carry the Interest Lifetime TLV, and 109 hence having compact encoding is particularly valuable for keeping 110 Interest messages short. 112 Since the current uses of delta time do not require both accuracy and 113 dynamic range simultaneously, one can consider a logarithmic encoding 114 such as that specified in [RFC5497] and outlined in Section 4. This 115 document updates CCNx messages in TLV Format ([RFC8609]) to permit 116 this alternative encoding for selected Time values. See Section 6 117 for the specific actions needed to register this alternative compact 118 representation of Interest Lifetime. 120 3.2. Absolute Time usage in CCNx 122 CCNx, as currently specified in [RFC8569], utilizes absolute time for 123 various important functions. Each of these absolute time usages 124 poses a different challenge for a compact representation. These are 125 discussed in the following subsections. 127 3.2.1. Signature Time 129 _Signature Time_ is the time the signature of a content object was 130 generated (sections 8.2-8.4 [RFC8569]). This is a content message 131 TLV and represents an absolute timestamp in milliseconds since the 132 UTC epoch (i.e. An NTP timestamp). It is currently encoded via the 133 T_SIGTIME TLV as a 64-bit unsigned integer (see section 3.6.4.1.4.5 134 [RFC8609]). 136 Given that a signature time could be essentially at any time in the 137 past, and is included in the hash securing the content object, it 138 seems there is no practical way to define an alternative compact 139 encoding that preserves its semantics and security properties; hence 140 we don't consider it further as a candidate. 142 3.2.2. Expiry Time 144 _Expiry Time_ indicates the expiry time of a content object (section 145 4 [RFC8569]). This is a content message TLV (covered by the hash and 146 signature of the content object) and represents an absolute timestamp 147 in milliseconds since the UTC epoch (i.e. An NTP timestamp). It is 148 currently encoded via the T_EXPIRY TLV as a 64-bit unsigned integer 149 (see section 3.6.2.2.2 [RFC8609]). 151 Expiry time could be in the past, or in the future, potentially by a 152 large delta, and is included in the hash securing the content object. 153 Therefore, it seems there is no practical way to define an 154 alternative compact encoding that preserves its semantics and 155 security properties; hence we don't consider it further as a 156 candidate. 158 3.2.3. Recommended Cache Time 160 _Recommended Cache Time_ (RCT) for a content object (see section 4 161 [RFC8569]) is a hop-by-hop header stating the expiration time for a 162 cached content object in milliseconds since the UTC epoch (i.e. An 163 NTP timestamp). It is currently encoded via the T_CACHETIME TLV as a 164 64-bit unsigned integer (see section 3.4.2 [RFC8609]). 166 Recommended cache time could be far in the future, but cannot be in 167 the past and is likely to be a reasonably short offset from the 168 current time. Therefore, this document allows the recommended cache 169 time to be interpreted as a relative time value rather than an 170 absolute time, since the semantics associated with an absolute time 171 value do not seem to be critical to the utility of this value. This 172 document therefore updates the recommended cache time with the 173 following rule set: 175 o Use absolute time as per [RFC8609] 177 o Use relative time, if the compact time representation is used (see 178 Section 4 and Section 5) 180 4. A Compact Time Representation with Logarithmic Range 182 This document defines a compact time representation with logarithmic 183 range support that is inspired by [RFC5497] and [IEEE.754.2019]. 184 Compact time-codes are one octet wide and represent time-values that 185 range from milliseconds to years. Figure 1 depicts the logarithmic 186 nature of this time representation. 188 || | | | | | | | | | | 189 +-----------------------------------------------------------------+ 190 milliseconds years 192 Figure 1: A logarithmic range representation allows for higher 193 precision in the smaller time ranges and still supports large time 194 deltas. 196 Time-codes encode an exponent and a mantissa as illustrated in 197 Figure 2. In contrast to the representation in [IEEE.754.2019], 198 time-codes only encode positive numbers and hence do not include an 199 extra sign bit. 201 <--- one octet wide ---> 202 +---+---+---+---+---+---+---+---+ 203 | exponent (e) | mantissa (m) | 204 +---+---+---+---+---+---+---+---+ 206 Figure 2: A time-code with exponent and mantissa to encode a 207 logarithmic range time representation. 209 The base unit for time values are seconds. A time-value is 210 calculated using the following formula, where (e) represents the 211 exponent, (m) the mantissa, (m_max) the maximum mantissa value, and 212 (b) the bias. 214 Subnormal (e == 0): (0 + m/m_max) * 2^(1+b) 216 Normalized (e > 0): (1 + m/m_max) * 2^(e+b) 218 The subnormal form is only applied when the exponent is zero. This 219 form provides a gradual underflow for the gap between the smallest 220 normalized number and zero. The normalized form is applied for all 221 values with an exponent greater than zero. 223 This document allocates "5" bits for the exponent and "3" bits for 224 the mantissa. Therefore, exponents have the range [0,31] and 225 mantissae have the range [0,7]. This document further applies a bias 226 of "-5". The following properties result from this configuration: 228 o Minimum subnormal number: 0 seconds 230 o Maximum subnormal number: ~0.054688 seconds 232 o Minimum normalized number: ~0.062500 seconds 234 o Maximum normalized numbers: [~3.46, ~3.72, ~3.99] years 235 Eight time values exist in the subnormal range [0,~0.054688s] with a 236 step size of ~0.007813s between each time value. In addition, this 237 configuration also encodes the following convenient numbers in 238 seconds: [1, 2, 4, 8, 16, 32, 64, ...]. 240 5. Protocol Integration of the Compact Time Representation in CCNx 241 Messages 243 A straightforward way to accommodate the compact time approach as an 244 alternative encoding is to simply allow a 1-byte length as an 245 alternative to the 8-byte length while retaining the existing TLV 246 Registry entries. This approach has backward compatibility problems, 247 but may still be considered for the following reasons: 249 o Both CCNx RFCs are experimental and not Standards Track, hence 250 expectations for forward and backward compatibility are not as 251 stringent. "Flag day" upgrades of deployed CCNx networks, while 252 inconvenient, are still feasible. 254 o The major use case for these compressed encodings are smaller- 255 scale IoT and/or sensor networks where the population of 256 consumers, producers, and forwarders is reasonably small. 258 o Since the current TLVs have hop-by-hop semantics, they are not 259 covered by any signed hash and hence may be freely re-encoded by 260 any forwarder. That means a forwarder supporting the new encoding 261 can translate freely between the two encodings. 263 o The alternative of assigning new TLV registry values does not 264 substantially mitigate the interoperability problems anyway. 266 The following lists alternative approaches of integrating the compact 267 time representation for time offsets in CCNx messages. A further 268 analysis, discussion, and decision on the best suited approach will 269 be added as the document progresses. 271 1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to 272 hint at the used encoding. This approach is the least intrusive 273 integration, but adds a TLV overhead that negates the benefits of 274 the compact time representation. 276 2. A new TLV type for T_INTLIFETIME with a compact time 277 representation (T_INTLIFETIME_COMPACT) is defined. The packet 278 header grammar from [RFC8609] is updated to allow for 279 T_INTLIFETIME_COMPACT at the same level of the currently defined 280 T_INTLIFETIME with an exclusive or. 282 6. IANA Considerations 284 Based on the approach of integration, certain TLV registries from 285 [RFC8609] need to be updated. 287 7. Security Considerations 289 This document makes no semantic changes to RFC8965, nor to any of the 290 security properties of the message encodings of RFC8609, and hence 291 has the same security considerations as those two existing documents. 293 8. References 295 8.1. Normative References 297 [IEEE.754.2019] 298 Institute of Electrical and Electronics Engineers, C/MSC - 299 Microprocessor Standards Committee, "Standard for 300 Floating-Point Arithmetic", June 2019, 301 . 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, 306 DOI 10.17487/RFC2119, March 1997, 307 . 309 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 310 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 311 DOI 10.17487/RFC5497, March 2009, 312 . 314 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 315 Networking (CCNx) Semantics", RFC 8569, 316 DOI 10.17487/RFC8569, July 2019, 317 . 319 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 320 Networking (CCNx) Messages in TLV Format", RFC 8609, 321 DOI 10.17487/RFC8609, July 2019, 322 . 324 8.2. Informative References 326 [I-D.irtf-icnrg-icnlowpan] 327 Gundogan, C., Schmidt, T., Waehlisch, M., Scherb, C., 328 Marxer, C., and C. Tschudin, "ICN Adaptation to LowPAN 329 Networks (ICN LoWPAN)", draft-irtf-icnrg-icnlowpan-06 330 (work in progress), November 2019. 332 Authors' Addresses 334 Cenk Gundogan 335 HAW Hamburg 336 Berliner Tor 7 337 Hamburg D-20099 338 Germany 340 Phone: +4940428758067 341 Email: cenk.guendogan@haw-hamburg.de 342 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 344 Thomas C. Schmidt 345 HAW Hamburg 346 Berliner Tor 7 347 Hamburg D-20099 348 Germany 350 Email: t.schmidt@haw-hamburg.de 351 URI: http://inet.haw-hamburg.de/members/schmidt 353 Dave Oran 354 Network Systems Research and Design 355 4 Shady Hill Square 356 Cambridge, MA 02138 357 USA 359 Email: daveoran@orandom.net 361 Matthias Waehlisch 362 link-lab & FU Berlin 363 Hoenower Str. 35 364 Berlin D-10318 365 Germany 367 Email: mw@link-lab.net 368 URI: http://www.inf.fu-berlin.de/~waehl