Huawei Technologies Duesseldorf GmbH

Riesstrasse 25 Munich D-80992 Germany cenk.gundogan@huawei.com

HAW Hamburg

Berliner Tor 7 Hamburg D-20099 Germany t.schmidt@haw-hamburg.de http://inet.haw-hamburg.de/members/schmidt

Network Systems Research and Design

4 Shady Hill Square Cambridge MA 02138 United States of America daveoran@orandom.net

TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany m.waehlisch@tu-dresden.de

Information-Centric Networking CCNx constrained networks compressed delta time IoT 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 .

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 () 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

• .  Introduction
• .  Terminology
• .  Usage of Time Values in CCNx
  • .  Relative Time in CCNx
  • .  Absolute Time in CCNx
• .  A Compact Time Representation with Logarithmic Range
• .  Protocol Integration of the Compact Time Representation
  • .  Interest Lifetime
  • .  Recommended Cache Time
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Test Vectors
• .  Efficient Time Value Approximation
• Acknowledgments
• Authors' Addresses

Introduction CCNx is well suited for Internet of Things (IoT) applications . Low-Power Wireless Personal Area Network (LoWPAN) adaptation layers (e.g., ) 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 , this document discusses the various cases of time values, proposes a compact encoding for delta times, and updates 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.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology of and 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

Usage of Time Values in CCNx

Relative Time in CCNx CCNx, as currently specified in , utilizes delta time for only the lifetime of an Interest message (see Sections , , , and of ). It is a hop-by-hop header value, and is currently encoded via the T_INTLIFE TLV as a 64-bit integer (). 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 and as outlined in . This document updates CCNx messages in TLV format to permit this alternative encoding for selected time values.

Absolute Time in CCNx CCNx, as currently specified in , 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.

Signature Time and Expiry Time Signature Time is the time the signature of a Content Object was generated (see Sections - of ). Expiry Time indicates the time after which a Content Object is considered expired (). 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 and of , 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.

Recommended Cache Time Recommended Cache Time (RCT) for a Content Object () 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 ). 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
• Use relative time, if the compact time representation is used (see Sections and )

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.

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 ) that was inspired by and . Its logarithmic encoding supports a representation ranging from milliseconds to years. depicts the logarithmic nature of this time representation.

A logarithmic range representation allows for higher precision in the smaller time ranges and still supports large time deltas. || | | | | | | | | | | +-----------------------------------------------------------------+ milliseconds years

Time codes encode exponent and mantissa values in a single byte. In contrast to the representation in , time codes only encode non-negative numbers and hence do not include a separate bit to indicate integer signedness. shows the configuration of a time code: an exponent width of 5 bits, and a mantissa width of 3 bits.

A time code with exponent and mantissa to encode a logarithmic range time representation. <--- one byte wide ---> +----+----+----+----+----+----+----+----+ | exponent (b) | mantissa (a) | +----+----+----+----+----+----+----+----+ 0 1 2 3 4 5 6 7

The base unit for time values is seconds. A time value is calculated using the following formula (adopted from and ), 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, ...]. 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 . 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.

Algorithm in pseudocode. 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)

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).

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 ( and ) 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.

Interest Lifetime The Interest Lifetime definition in 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 ). For any other length, Interest Lifetimes are encoded as described in .

Changes to the definition of the Interest Lifetime TLV. 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 | +---------------+

Recommended Cache Time The Recommended Cache Time definition in 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 ). For any other length, Recommended Cache Times are encoded as described in .

Changes to the definition of the Recommended Cache Time TLV. 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 | +---------------+

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.

IANA Considerations This document has no IANA actions.

Security Considerations This document makes no semantic changes to , nor to any of the security properties of the message encodings described in ; 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 (). Otherwise, a legacy forwarder interprets time codes as absolute time values far in the past, which impacts cache utilization.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification. Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification. This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. Informative References HAW Hamburg HAW Hamburg HAW Hamburg FU Berlin Computer Communications, Vol. 164, No. 1, p. 114-123, Elsevier IEEE This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK] This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

Test Vectors The test vectors in show sample time codes and their corresponding time values according to the algorithm outlined in . Test Vectors

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

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 , 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 and for their valuable feedback on the encoding scheme and protocol integration. Special thanks also go to for his constructive in-depth comments during the IRSG review.

Authors' Addresses Huawei Technologies Duesseldorf GmbH

Riesstrasse 25 Munich D-80992 Germany cenk.gundogan@huawei.com

HAW Hamburg

Berliner Tor 7 Hamburg D-20099 Germany t.schmidt@haw-hamburg.de http://inet.haw-hamburg.de/members/schmidt

Network Systems Research and Design

4 Shady Hill Square Cambridge MA 02138 United States of America daveoran@orandom.net

TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany m.waehlisch@tu-dresden.de