Internet-Draft | SCHC Streaming Mode | May 2023 |
Aguilar & Gomez | Expires 12 November 2023 | [Page] |
- Workgroup:
- schc Working Group
- Internet-Draft:
- draft-aguilar-schc-streaming-00
- Updates:
- 8724 (if approved)
- Published:
- Intended Status:
- Standards Track
- Expires:
SCHC Streaming Mode
Abstract
This documents presents an update of SCHC [RFC8724] by providing a new F/R mode called SCHC Streaming mode.¶
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 12 November 2023.¶
Copyright Notice
Copyright (c) 2023 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.¶
1. Introduction
SCHC [RFC8724] provides Fragmentation/Reassembly (F/R) modes, i.e., No-ACK, ACK-Always and ACK-on-Error. These modes allow for SCHC Packets larger than the Maximum Transmission Unit (MTU) of the underlying Layer 2 (L2) to be transferred between the sender and receiver with a range of reliability options, including SCHC Fragment retransmissions, over delay tolerant networks. The available F/R modes allow transmitting non-fragmented SCHC Packets concurrently with fragmented SCHC Fragments, and SCHC Packet interleaving. However, SCHC does not provide an optimal F/R mode for a continuous transmission of un-fragmented SCHC Packets, i.e, streaming of SCHC Packets smaller than, or of the same size as, the L2 MTU.¶
The streaming of SCHC Packets can be used to send, e.g., sensor measurements or the location coordinates of an asset tracker, which are sent every number of minutes and are optimized to fit in only one SCHC Fragment, with or without SCHC Compression. These SCHC Packets may not require fragmentation but require reliability, as some fragment losses may be incurred due to intermittent connectivity (e.g., vehicles going into tunnels, no coverage areas) or opportunistic coverage (e.g., coverage is available for certain time windows, of duration and frequency that might not be deterministic). With current SCHC F/R modes, each sensor measurement or location information can be sent as a compressed or un-compressed SCHC Packet, with different reliability options, however, each SCHC Packet will require a SCHC ACK, even if it is of only one SCHC Fragment in size. In networks, e.g., LPWANs [RFC8376], the downlink traffic or network capacity may be limited. [I.D.Compound ACK] provides an optimization in the ACK traffic by grouping the feedback of several windows of tiles in the same ACK message, providing flexibility on when the receiver sends feedback.¶
The present document extends [RFC8724] with a new F/R mode called SCHC Streaming. This F/R mode optimized the overhead of current F/R modes for a contiuos streaming of compressed or un-compressed SCHC Packets which require one SCHC Fragment to be transferred. The SCHC Streaming mode provides different configuration option on when the receiver can provide feedback, therefore adapting to the specifics of each network, e.g., the amount of ACK traffic that can be supported, application delay tolerance, L2 MTU size and the maximum number of window bitmaps that can be carried in a SCHC Compound ACK.¶
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and in [RFC8724], specially Section 8.¶
3. SCHC Streaming
The SCHC Streaming mode supports L2 technologies that have variable MTU and out-of-order delivery (to some extent). It requires an L2 that provides a feedback path from the reassembler to the fragmenter.¶
SCHC Streaming mode uses windows, with all tiles, except for the last one, of equal size (regular size). The last tile MAY be smaller or equal to a regular tile.¶
A SCHC Fragment carries one or several contiguous tiles, which may span multiple windows from the same DTag value. A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number and corresponding to the same DTag value.¶
Each Profile, for each RuleID value, MUST define:¶
- the tile size (a tile does not need to be multiple of an L2 Word, but it MUST be at least the size of an L2 Word),¶
- the value of M,¶
- the value of N,¶
- the value of WINDOW_SIZE, which MUST be strictly less than 2^N,¶
- the size and algorithm for the RCS field,¶
- the value of T,¶
- the value of MAX_ACK_REQUESTS,¶
- the expiration time of the Retransmission Timer,¶
- the expiration time of the Inactivity Timer,¶
- when the SCHC Compound ACKs are sent.¶
For each active RuleID value, the sender MUST maintain:¶
For each active RuleID value, the receiver MUST maintain:¶
3.1. Transfer Cycles
In SCHC Streaming mode the flow of tiles is continuous and it is divided into cycles. There are two cycles, the Window Cycle and the DTag Cycle (see Figure 1). To uniquely identify each tile, a combination of DTag, Window Number and FCN is used in each DTag Cycle.¶
The sender will begin the first DTag and Window Cycle by sending tiles using DTag = 0 and Window Number = 0 (the tile index, i.e., the FCN, MUST be decremented by 1 from WINDOW_SIZE - 1 downward). After each window of tiles, the Window Number is increased. Current Window Cycle ends once the Window Number reaches its maximum value and the last fragment of this window is sent. Next Window Cycle will begin by increasing the DTag value by one, and resetting the Window Number and FCN values. The number of Window Cycles without repeating the same DTag, Window Number and FCN value depends on the size of the DTag field, which determines the DTag Cycle. After the DTag reaches its maximum value, and therefore the end of the DTag Cycle, it MUST be reset. To manage the receiver feedback, the Receiver MUST send at least one SCHC Compound ACK per DTag Cycle, i.e., before the DTag is reset, indicating tiles losses in any of previous Window Cycles corresponding to this DTag Cycle. Only one Window Cycle MUST be reported per SCHC Compound ACK. The SCHC Compound ACK MUST be sent before the start of a new DTag Cycle. SCHC Fragments MAY be delivered out-of-order in each DTag Cycle, but all tiles MUST be received before advancing to the next DTag Cycle.¶
The SCHC All-1 message is used to finalize current SCHC Streaming session in case it is needed.¶
3.2. ACK Behaviour
A SCHC Compound ACK MAY be sent after the All-0 SCHC Fragment message and MUST be sent after the All-1 SCHC Fragment message. This allows the receiver to provide feedback after any window of tiles. The Profile MUST specify when the sender should listen for a SCHC Compound ACK, specially in networks which require the sender to enable reception of incoming SCHC ACKs. The sender MAY listen after each complete window of tiles (the All-0 message in each window), after the All-0 of the last window of each Window Cycle or after the All-0 of the last window of each DTag Cycle.¶
The receiver can send SCHC Compound ACKs:¶
- at the end of each Window Cycle, in the last window (with the maximum window number), an All-0 message indicates the end of current window, and as it is the last window of current Window Cycle, it indicates the end of current Window Cycle. The receiver MAY send a SCHC Compound ACK. Note that after this Window Cycle ends, the receiver MAY request fragments of previous DTag values (before the DTag Cycle ends).¶
- A success SCHC ACK MUST be sent by the receiver at the end of each DTag Cycle, to acknowledge all SCHC Fragment before continuing to next DTag Cycle. Note that after a new DTag Cycle begins, it is not possible to recover SCHC Fragment from previous DTag Cycles, as the combination of DTag, Window Number and FCN is repeated.¶
4. SCHC Streaming mode examples
This section provides examples of the SCHC Streaming mode. The configuration used in these examples is as follows:¶
- RuleID: Same RuleID in all SCHC Fragments.¶
- M: 2 bits (with values 00,01,10,11)¶
- N: 3 bits (with values from 6 to 0 plus the All-1)¶
- DTag: 1 bits¶
- WINDOW_SIZE: 7 tiles¶
In Figure 2, a SCHC Streaming transmission example is shown. In this transmission, the first 3 windows have fragment losses. The fourth window has no fragment losses. The receiver sends a SCHC Compound ACK reporting on the fragment losses of the first 3 windows, after receiving the All-0 message that signal the end of current Window Cycle, i.e., the All-0 message of the fourth window. The sender resends the missing fragments and continues to next Window Cycle by increasing the DTag value.¶
Next Window Cycle present fragment losses that are recovered at the end of the cycle, as the receiver sends a SCHC Compound ACK message after receiving the All-0 message. The sender resends the missing fragment, and as it is the end of the DTag Cycle, a success ACK is sent by the receiver to continue the transmission in the next DTag Cycle.¶
Figure 3 shows another example of SCHC Streaming mode where a SCHC Compound ACK is sent at the ending of the DTag Cycle, recovering SCHC Fragment losses of previous windows of the DTag Cycle. As both Window Cycles present SCHC Fragment losses, two SCHC Compound ACKs are sent by the receiver at the end of the DTag Cycle.¶
Figure 4 presents a SCHC Streaming transmission that is closed by the sender using an All-1 message. After the All-1 message, the receiver sends a SCHC Compound ACKs for missing fragments. The sender resends missing fragments and waits for a success SCHC ACK indicating that all SCHC Fragments were correctly received and that current SCHC Streaming transmission can be closed.¶
Figure 5 shows a SCHC Streaming example where the receiver aborts current transmission.¶
5. SCHC Streaming mode YANG Data Model
The present document also extends the SCHC YANG data model defined in [RFC9363] by including a new identity in the fragmentation mode type.¶
7. IANA Considerations
This document has no IANA actions.¶
8. Acknowledgements
Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant, and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033), and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya 2017 through grant SGR 376.¶
Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).¶
9. References
9.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8724]
- Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.
- [RFC9363]
- Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, , <https://www.rfc-editor.org/info/rfc9363>.
9.2. Informative References
- [RFC8376]
- Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, , <https://www.rfc-editor.org/info/rfc8376>.