SCHC Rule Format for Message Aggregation in Delay Tolerant Networks

Internet-Draft	SCHC Rule Format for Message Aggregation	February 2025
Pelov	Expires 8 August 2025	[Page]

Abstract

This document defines a new Rule Format for Message Aggregation (referred to as Aggregation) within the SCHC framework. By bundling multiple SCHC-compressed packets into a single Aggregation Data Unit (ADU), the mechanism reduces the number of transmissions required in delay-tolerant networks. The Aggregation process is triggered by conditions such as reaching the L2 Maximum Transmission Unit (MTU), exceeding a maximum delay, or meeting a minimum packet rate threshold. This new rule type is backward compatible with existing SCHC operations and offers an efficient solution for energy-sensitive and asymmetric communication scenarios.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 August 2025.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

Low-power, delay-tolerant networks benefit significantly from minimizing the number of transmissions to conserve energy. The Static Context Header Compression (SCHC) framework, as described in RFC8724, already provides mechanisms for compressing and fragmenting IPv6/UDP packets for LPWANs. This document introduces an additional SCHC Rule Type—Aggregation—which enables the bundling of multiple SCHC-compressed packets into a single Aggregation Data Unit (ADU). The Aggregation mechanism is particularly beneficial when latency is acceptable in exchange for reduced network traffic and improved energy efficiency.¶

2. Aggregation Overview

In the proposed architecture, an application packet is first processed by the SCHC Compression module. The compressed packet is then passed to the Aggregation module, which appends an Aggregation RuleID and a size field to the compressed payload. Multiple such packets are concatenated into one ADU. The ADU is transmitted to the lower layers based on one or more of the following triggers:¶

MTU Threshold: When the cumulative size of aggregated data reaches the L2 Maximum Transmission Unit.¶
Maximum Delay: When the waiting time in the aggregation buffer exceeds a configured maximum delay.¶
Minimum Packet Rate: When a periodic condition (e.g., a transmission scheduled once per day) is met in low-traffic scenarios.¶

3. SCHC Aggregation Rule Specification

The Aggregation Rule defines the packet format and processing steps for bundling SCHC-compressed packets. The following figure illustrates the structure of an Aggregation packet:¶

|------ SCHC Aggregation Header -------------|-- SCHC Compressed Payload ---|
|------- RuleID -------|-- Size Field -------|
+---------+------------+---------------------+------------------------------+~~~~~~~~~~~~~~~~~~~~~~~~+
| Aggregation RuleID   | Size Field (N bits) | Compressed Packet Payload | (Optional additional segments)
+---------+------------+---------------------+------------------------------+~~~~~~~~~~~~~~~~~~~~~~~~+

Figure 1: SCHC Aggregation Packet Format

Each aggregated segment contains:¶

Aggregation RuleID: A unique identifier indicating that the packet has undergone aggregation.¶
Size Field: An N-bit field (with N defined in the SCHC Context) specifying the length in bytes of the compressed payload.¶
Compressed Payload: The output from the SCHC Compression process.¶

Additional SCHC-compressed packets are concatenated using the same "Size Field + Compressed Payload" structure. Note that there is no need fo Aggregation RuleID for the subsequent packets in one ADU.¶

3.1. Aggregation Triggers

The Aggregation module maintains a buffer of compressed packets and transmits the ADU when one or more of the following conditions is met:¶

MTU Threshold: The total size of the ADU equals or exceeds a threshold, e.g. equal to the L2 MTU.¶
Maximum Delay: The time a packet remains in the aggregation buffer exceeds a preconfigured maximum delay.¶
Minimum Packet Rate: A periodic trigger (e.g., transmitting at least once per day) ensures that packets are not delayed indefinitely in low-traffic conditions.¶

4. Operational Considerations

The Aggregation mechanism offers significant energy savings by reducing the number of transmissions; however, it introduces several trade-offs:¶

Delay versus Efficiency: While aggregation reduces transmissions, it inherently introduces additional delay. This is acceptable in delay-tolerant networks but must be carefully tuned to meet application requirements.¶
Error Recovery: Loss or corruption of an ADU can affect multiple SCHC packets simultaneously. Implementations must include strategies for error detection and potential recovery of aggregated data.¶
Buffer Management: Efficient management of the aggregation buffer is crucial to ensure that packets are aggregated and transmitted in a timely manner, especially under fluctuating network conditions.¶

5. Flow Diagram

The following diagram illustrates the data flow from SCHC Compression to Aggregation and subsequent transmission:¶

+-----------------+       +---------------------+       +-----------------------+
| Application     | ----> | SCHC Compression    | ----> | SCHC Aggregation      |
| Data Packet     |       | (Compressed Data)   |       | (Aggregation Buffer)  |
+-----------------+       +---------------------+       +-----------+-----------+
                                                                |
                                                                v
                                                     +-----------------------+
                                                     | Lower Layers (L2)     |
                                                     | Transmission of ADU   |
                                                     +-----------------------+

Figure 2: Data Flow for SCHC Aggregation

Note that the PDU of the SCHC Aggregation can be sent to other SCHC processes.¶

6. Security Considerations

Aggregating multiple SCHC-compressed packets into a single ADU can increase the impact of packet interception or corruption. To mitigate these risks, the integrity mechanisms employed during SCHC Compression must be extended to cover the entire ADU. In addition, implementations should:¶

Apply end-to-end integrity checks on the aggregated data.¶
Consider mechanisms to detect and recover from partial data loss in an ADU.¶

8. Examples and Use Cases

8.1. Example: Periodic Sensor Data Aggregation

In a sensor network, individual sensor readings are first compressed using SCHC Compression. The Aggregation module then collects these compressed packets over a period (e.g., one day) and bundles them into an ADU. This reduces the number of uplink transmissions, thereby conserving energy while accommodating delay-tolerant reporting.¶

8.1.1. Example: MTU-Triggered Aggregation

In scenarios with higher traffic, multiple SCHC-compressed packets are buffered until their combined size approaches the L2 MTU. The ADU is then transmitted immediately, optimizing channel usage and reducing overhead.¶