]> Ericsson

lorenzo.corneo@ericsson.com

Ericsson

edgar.ramos@ericsson.com

Ericsson

jaime.jimenez@ericsson.com

Applications SCHC Working Group This document describes techniques to adapt the SCHC framework (RFC8724), used for header compression, to also compress and decompress payload of specific protocols. To this end, this document defines a new matching operator, equal-template, to check equality of field values with respect to a user-defined template, and a payload keyword to be used as Field IDentifier (FID) to signal the presence of payload to be compressed or decompressed. Additionally, this document defines a set of template functions and variables to optimize user-defined templates, which can be extended through the IANA registry defined herein. About This Document Status information for this document may be found at . Discussion of this document takes place on the schc Working Group mailing list (), which is archived at . Subscribe at .

Introduction The main purpose of this document is to extend the SCHC framework to compress and decompress structured data payloads, e.g., JSON , reusing the same compression and decompression machinery originally designed for protocol headers. This document defines the equal-template Matching Operator (MO), which enables a SCHC compressor to match a field value against a user-defined template and extract only the variable parts as compression residue. Templates may include positional variables and functions to address common patterns in structured data. Additionally, this document defines the payload keyword for use in the Field IDentifier (FID) to signal that payload compression is being performed. The keyword can be used with a template, where the entire payload structure is captured in the Target Value (TV), or without a template, where individual structured data fields are specified in separate rule entries.

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 () () when, and only when, they appear in all capitals, as shown here.

Glossary

• Template-based compression: Payload compression utilizing a pre-shared model that only requires the values that are changing in the payload.
• Template variable: A template variable can be used as a placeholder for variable fields in a template definition. Template variables can carry semantics and other information, e.g., the position and size of a field value in the compression residue (see ).
• Template function: A template function can be used to perform actions on a template definition, e.g., compress repeated structures in the payload (see ).
• Payload keyword: The keyword payload used in the FID to signal that payload compression is being performed.

A Matching Operator Providing Equality over Templates This section introduces the equal-template Matching Operator (MO), which evaluates equality between a field value and a provided template specified in the Target Value (TV).

Matching Procedure The equal-template MO MUST perform the following steps:

1. Parse the template specified in the TV to identify the fixed portions and the positions of template variables (see ) and functions (see ).
2. Compare the fixed portions of the template against the corresponding portions of the field value. The comparison MUST be performed as a byte-wise exact match on the textual representation of the field value.
3. Extract the substrings of the field value that correspond to each template variable. Each extracted substring represents a value to be included in the compression residue.
4. If all fixed portions match, the MO evaluates to true and the extracted values are passed to the Compression/Decompression Action (CDA). If any fixed portion does not match, the MO evaluates to false and the rule MUST NOT be applied.

Residue Encoding When the equal-template MO evaluates to true, the extracted values MUST be encoded in the compression residue in the order determined by their positional identifiers (i.e., $1 before $2, and so on). Each positional template variable MUST specify the length of the value it captures, expressed in bytes, using the notation $n:length. For example, $1:10 indicates that the first positional variable captures a value occupying exactly 10 bytes in the residue. If the actual extracted value is shorter than the declared length, it MUST be right-padded with zeros to fill the declared length. Upon decompression, the decompressor MUST strip trailing zero bytes from each extracted value before reconstructing the payload. This is safe because the equal-template MO operates on textual representations where the null byte (0x00) is not a valid character. The decompressor uses this fixed length to unambiguously parse the residue. This approach keeps the length information co-located with the template variable it describes and does not require changes to the SCHC rule structure defined in . Alternatively, the Field Length (FL) field of the rule could be extended to carry a list of lengths, one per positional variable. Such an approach would require additional standardization effort and is left for future discussion within the Working Group.

Type Handling The equal-template MO operates on the textual (serialized) representation of the field value. Template variables capture substrings as-is, preserving the original serialization. For example, given the template {"value": $1:4} and the field value {"value": -11}, the extracted value for $1 is the string -11 right-padded with one zero byte to fill 4 bytes. Type interpretation is left to the application layer after decompression.

Match Failure If the equal-template MO evaluates to false for a given rule, the SCHC compressor MUST proceed to evaluate the next rule in the rule set, as specified in Section 7.2 of . If no rule matches, the packet MUST be sent uncompressed.

Template Variables and Functions This section specifies one variable and one function, to be used in templates, that address common patterns in structured data. Template variables and functions are identified through a special character, hereby defined as the dollar sign $. It is possible to define additional template variables and functions in the IANA registry defined in .

Positional Template Variable The positional template variable, $n:length, uses a numerical identifier, n, to represent the position of the field value in the compression residue, and a length to specify the fixed size in bytes of the captured value (see ). That is, $1:10 represents the first field value in the residue with a fixed length of 10 bytes, while $2:4 represents the second one with 4 bytes. For example, a target value (TV) using two positional template variables may look as follows: Considering the above example, the MO equal-template will match the following payload: As a result, the values "abc123" and -11 will be encoded in the residue during compression phase, while the rest of the template will be elided. Note that since the matching is byte-wise (see ), the positional variable captures exactly the substring between the surrounding fixed portions. In this example, $1 captures "abc123" including the JSON quotes (8 bytes), while $2 captures -11 without quotes (3 bytes).

Repeat Template Function The repeat template function, $repeat(template, separator), is used to repeat multiple times the template passed as argument. The function requires two arguments as input, namely, the template to repeat, and the separator between template repetitions. The example below is indicative of a common pattern found in structured data payloads. Using the repeat template function, $repeat(), the above example may look as follows: As noted above, it is possible to use the repeat template function, $repeat(), in conjunction with the positional template variable, $n.

Repetition Count The number of repetitions is not known a-priori from the template and varies per payload. The compressor MUST infer the number of repetitions by matching the template against the field value, and MUST encode this count as the first byte of the residue for the $repeat() block, as an unsigned 8-bit integer. The decompressor MUST read this count first, then extract the positional variable values for each repetition in sequence. For the example above with two repetitions, the residue is structured as follows: Since each positional variable has a fixed length declared via the $n:length notation (see ), the decompressor knows that each repetition contributes a fixed number of bytes to the residue. In the example above, each repetition contributes 14 bytes (10 + 4). A repetition count of zero is valid. In this case, the residue for the $repeat() block contains only the count byte (0x00), and the decompressor MUST reconstruct an empty sequence, retaining only the surrounding fixed portions of the template. However, a repetition count of zero is discouraged as it likely indicates a misconfigured rule or an unexpected payload structure. Since the repetition count is encoded as an unsigned 8-bit integer, the maximum number of repetitions is 255. This is expected to be sufficient for constrained IoT use cases. Whether a larger count field is needed is left for discussion within the Working Group.

Positional Variable Scope Positional variable identifiers ($n) are scoped to a single repetition. That is, $1 and $2 refer to the first and second extracted values within each repetition, not across the entire payload. The residue contains the values for all positional variables of the first repetition, followed by those of the second repetition, and so on.

Optimization Example The level of payload compression that can be achieved greatly varies depending on the use case. For example, if it is known a-priori that the value of the field id never changes, the above payload example could be further optimized as follows: The above template allows the compressor to avoid adding the value of the field id to the residue, unlike in the previous example.

A Keyword for Structured Data Payload Compression This section defines the keyword payload that MUST be used whenever payload compression is needed. In such cases, the keyword payload MUST be specified in the Field IDentifier (FID). When payload compression is performed by individually specifying one structured field at a time, the FID MUST include the keyword payload as prefix, followed by a colon : and the name of the structured data field, e.g., payload:name for the structured data field called name. An extended FID notation that includes additional context such as media type and field index is illustrated in . Whether such extended notation should be normative is left for discussion within the Working Group. When payload compression is provided through a template, thus all the structured data fields are included in the TV, the FID MUST include only the keyword payload.

An Example of Structured Data Payload with Template This section demonstrates the use of the equal-template matching operator (MO) in conjunction with payload compression templates and the payload keyword. Considering the example below a SCHC rule (with only relevant fields) MAY be defined using the new payload keyword, the equal-template MO, and the payload compression templates (functions and variables). Such a rule may look as follows: equal-template send ]]> where the <template> is omitted from the above for brevity, but is defined as follows: When a SCHC node computes the rule above, the payload keyword in the FID signals the node that application data needs to be compressed. Specifically, the equal-template MO triggers the SCHC node to check for equality between the current field value and the template provided in the TV. Upon matching, the residue is sent (or retrieved) over the network. For the payload above, the residue contains the repetition count (0x02, 1 byte) followed by the values -11 and -13, each padded to 4 bytes. Please notice that the algorithm used to perform template matching is implementation-specific, provided that the result is equivalent to the matching procedure defined in .

An Example of Structured Data Payload without Template This section demonstrates how to make use of payload compression without a template as defined in this document. The example below will be the target of the payload compression. The snippet below shows how a SCHC rule (only relevant fields are used) MAY be defined using the new payload keyword. The FIDs in the rule above carry semantics that can be used by the SCHC node to perform successful compression and decompression. Considering the first field of the above rule, application/json signals the decompressor which media type is being reconstructed. The subsequent numerical identifier, 1, represents the object the compressed field belongs to. Finally, the last value encoded in the FID is the name of the JSON object, id. Moreover, the target value (TV) corresponds to the value of the structured data field, and not to the name. In the second field of the above rule, the TV is omitted as the send CDA implies that the decompressor reads the received residue. However, in this case, the decompressor knows that the residue must be assigned to the JSON field specified in the FID, value in this case. Please notice that the semantics of the FID described above are not normative. Semantic-specific details of the FID are left to implementations as this document only mandates the payload keyword.

Security Considerations The security considerations of the SCHC framework apply to this document. This document does not define any encryption mechanism. If payload confidentiality is required, it MUST be provided by a lower layer or by encrypting the payload before compression.

IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this document, in accordance with .

SCHC Payload Compression Template Functions and Variables IANA is requested to create a new registry called "SCHC Payload Compression Template Functions and Variables". The registration policy for this registry is "Specification Required" as defined in Section 4.6 of . The registry MUST include the following fields: - Name of function or variable - Type (function or variable) - Description - Reference of the specification describing the function or variable The designated expert(s) SHOULD verify that the template function, or variable, name is appropriate and not likely to cause confusion with existing entries. The registrant of an existing entry may request updates to that entry, subject to the same expert review. They should verify that updates preserve backward compatibility with deployed implementations, or if breaking changes are necessary, consider whether a new registry entry is more appropriate. The following template functions and variables are described in this document: SCHC Payload Compression Template Functions and Variables Registry

Function/Variable Name	Type	Description	Reference
n	variable	Positional Template Variable	This document,
repeat	function	Repeat Template Function	This document,

References Normative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. Informative References JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

Acknowledgements A great token of appreciation to Rajat Kandoi and Ari Keränen for their support in the inception and review of this draft. Their ideas and thinking are also reflected in the text of the draft.

Preliminary ABNF for Template Syntax This appendix provides a preliminary ABNF (RFC 5234) grammar for the template syntax defined in this document. This grammar is work in progress and is subject to discussion and agreement within the SCHC Working Group.