| Internet-Draft | SCHC Rule Format for Reliability Fragmen | February 2025 |
| Pelov | Expires 8 August 2025 | [Page] |
This document specifies a new Rule Format for Reliability Fragmentation within the SCHC framework. Building on the fragmentation mechanisms defined in RFC8724, this rule format is tailored to ensure the reliable delivery of small messages that do not trigger conventional fragmentation. A key enhancement is the inclusion of a size field, indicating the total byte-length of the message, and modifications to the state machine to support a persistent session with wrap-around windows. Two operational modes are defined:¶
RelNoAck: A mode derived from SCHC No-Ack fragmentation, where fragments are transmitted continuously without expecting per-fragment acknowledgments. Losses are tolerated within a configured threshold.¶
RelAckOnErr: A mode derived from SCHC Ack-On-Error fragmentation, where the receiver actively monitors for missing fragments and initiates recovery through explicit negative acknowledgments.¶
These modes offer operators the flexibility to balance recovery overhead against latency and reliability requirements in constrained network environments.¶
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 (c) 2025 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 (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.¶
RFC8724 specifies the SCHC framework for compressing and fragmenting IPv6/UDP packets for LPWANs. While its fragmentation mechanism efficiently segments large messages, small messages that do not meet the fragmentation threshold remain vulnerable to loss due to the absence of recovery procedures. This document introduces a new Rule Format for Reliability Fragmentation that adapts SCHC Fragmentation for small-message reliability. It does so by adding a size field to every fragment and by modifying the state machine to maintain a persistent session with cyclic windowing, thereby enabling recovery even when individual fragments are lost.¶
The fundamental enhancement in Reliability Fragmentation is the extension of SCHC Fragmentation to small messages. This is achieved by:¶
Adding a Size Field: Each fragment carries an additional field indicating the total size (in bytes) of the SCHC-compressed message. This allows the receiver to understand the complete expected payload even when messages are not naturally segmented.¶
Persistent Session with Wrap-Around Windows: Unlike conventional fragmentation where the session terminates upon complete message reassembly, the Reliability Fragmentation session remains open indefinitely. The window indices wrap around, enabling recovery only within the bounds of the maintained window memory.¶
Dual Operational Modes: Two distinctly different modes are defined to address diverse network conditions:¶
RelNoAck mode is derived from the SCHC No-Ack fragmentation mechanism. Its main characteristics are:¶
Continuous Transmission: Fragments are sent continuously without waiting for acknowledgments for each fragment.¶
Size Field Utilization: The inclusion of a size field enables the receiver to immediately ascertain the complete message length, even if fragments arrive out of sequence.¶
Loss Tolerance: In the absence of acknowledgment-driven recovery, a configurable threshold of tolerated loss is defined. If fragment loss remains within this threshold, the upper layers may accept a partial reassembly.¶
Simplified State Machine: The state machine does not trigger explicit recovery procedures upon detecting a missing fragment. Instead, fragments are forwarded as they arrive, and any gaps are either ignored or handled by upper-layer protocols if the loss is deemed acceptable.¶
This mode is ideal for networks where retransmission overhead is undesirable and where some loss does not critically affect application performance.¶
RelAckOnErr mode builds on the SCHC Ack-On-Error fragmentation mechanism. Its operation involves:¶
Error Detection: The receiver monitors the sequence of fragments using the embedded RuleID and fragmentation parameters.¶
Explicit Recovery Trigger: If a fragment is identified as missing within the active window, the receiver generates a negative acknowledgment or error report to the sender.¶
Retransmission Mechanism: Upon receiving the error notification, the sender retransmits the missing fragment(s) to ensure complete message reconstruction.¶
Enhanced Reliability: This mode provides robust recovery, ensuring that even if one or more fragments are lost, the complete message is eventually delivered without error.¶
Dynamic Window Management: The state machine continuously manages the cyclic window, tracking received and missing fragments, and initiating recovery procedures only within the window's scope.¶
RelAckOnErr is best suited for applications where data integrity is critical and where the overhead of retransmissions is justified by the need for complete and error-free delivery.¶
The packet format for Reliability Fragmentation extends the SCHC Fragmentation format specified in RFC8724 with an additional size field. The structure is as follows:¶
|---- SCHC Reliability Fragmentation Header ----|-- Size Field --|--- Data Segment --------| | RuleID | Flags & Mode | ... | (N bits) | Compressed Payload | +--------+--------------+-----------------------+----------------+-------------------------+
Reliability RuleID: Identifies that the packet adheres to the Reliability Fragmentation format.¶
Flags & Mode: Indicate the operational mode (RelNoAck or RelAckOnErr) and other control parameters.¶
Size Field: An N-bit field, defined in the SCHC Context, representing the total byte-length of the compressed message.¶
Data Segment: The payload portion produced by SCHC Compression or Aggregation.¶
The state machine for Reliability Fragmentation is adapted from the SCHC Fragmentation state machine in RFC8724 with the following key modifications:¶
Persistent Session:
The session remains open after the complete transmission of a message, allowing the state machine to support continuous monitoring and recovery within a cyclic window.¶
Window Wrap-Around:
Sequence numbers or window indices wrap around. Recovery procedures are constrained to the current window maintained in memory, ensuring resource constraints are respected.¶
Mode-Specific Behavior:¶
In RelNoAck mode, the state machine does not wait for acknowledgments; fragments are processed immediately, and gaps are tolerated within a configured loss threshold.¶
In RelAckOnErr mode, the state machine actively monitors for missing fragments. Upon detecting a gap, it triggers a recovery procedure that requests retransmission of the missing fragment(s).¶
The design of Reliability Fragmentation is intended to seamlessly integrate with existing SCHC operations while providing enhanced reliability for small messages. Key considerations include:¶
Immediate Upper-Layer Delivery:
In both modes, received fragments are promptly forwarded to the upper layers. The size field assists in determining when the full message has been received.¶
Policy Flexibility:
Network operators can select between the SEND_OUT_OF_ORDER behavior (suitable for RelNoAck) and SEND_IN_ORDER behavior (necessary for RelAckOnErr) based on application latency and recovery requirements.¶
Dynamic MTU Adaptation:
Changes in the L2 Maximum Transmission Unit require dynamic adjustment of the window size. The system ensures that all fragments adhere to the current MTU, preserving data integrity.¶
The diagram below illustrates the flow of data through the Reliability Fragmentation process:¶
+-------------------+ +-----------------------------+ +--------------------------------+
| Application Data | ----> | SCHC Compression Module | ----> | Reliability Fragmentation |
| Packet | | (Compressed Data) | | (Fragmentation & Recovery) |
+-------------------+ +-----------------------------+ +---------------+----------------+
|
v
+--------------------------------+
| Lower Layers (L2 Transmission) |
| of Reliability Fragments |
+--------------------------------+
The modifications introduced by Reliability Fragmentation, such as the persistent session and additional size field, do not fundamentally alter the SCHC security model defined in RFC8724. Implementations must ensure that integrity and authenticity checks cover all fragments and that recovery procedures do not create new vulnerabilities.¶
No IANA Considerations.¶
In a sensor network where data is periodically transmitted, the RelNoAck mode is employed. Sensors compress their data using SCHC Compression, and the resulting packets are processed by the Reliability Fragmentation module. Fragments are sent continuously without waiting for acknowledgments, and the size field enables the receiver to piece together the complete message. Occasional losses are tolerated within a predefined threshold, making this mode suitable for non-critical monitoring applications.¶
In applications where data integrity is paramount, such as in industrial monitoring, the RelAckOnErr mode is utilized. Here, the receiver monitors the sequence of fragments and, upon detecting any missing fragment within the active window, sends a negative acknowledgment to trigger retransmission. This ensures that even in the presence of losses, the complete message is eventually reassembled without error.¶