| Internet-Draft | SCHC for Flow | October 2023 |
| Toutain & Minaburo | Expires 14 April 2024 | [Page] |
This document describes how to compress the header of packets belonging to a flow using Static Context Header Compression and Fragmentation (SCHC) specifications.¶
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 14 April 2024.¶
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.¶
This document defines how to use Static Context Header Compression and fragmentation (SCHC) [RFC8724] and [RFC8824] for compressing the headers of packets in a flow.¶
SCHC compresses headers of individual packets without any dependency among them, it does not have the notion of flow. In a flow, some information on the header change in each packet. When using SCHC, the information described in the Rule MAY change to consider this dependency. This document solves the possibility of optimizing the use of SCHC while compressing the flow packet headers.¶
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.¶
This document will follow the terms defined in [RFC8724] and in [RFC8824].¶
This document does not change the way SCHC compresses and chooses a Rule. The behavior defined in [RFC8724] is respected. SCHC compressor compresses each packet separately and MAY select the best behavior Rule for each packet. For instance, an action in the Rule indicates that the description compresses the header of a flow, and the compressor will process the packets using the action Derivable behavior.¶
This Action identifies those Rules describing protocol headers using flows to transmit payloads such as TCP, RTP, SCTP, or any other protocol. When SCHC compresses a packet belonging to a flow, it MUST first identify whether it belongs to a flow. SCHC will check the IP addresses and the ports and keep a reference value for the sequence number, the timestamp, and any other field that maintain the flow description. The fields describing a flow are out of the scope of this document. Each protocol MUST define the corresponding fields.¶
The following packets belonging to a flow will use a Derived Rule which updates the fields changing on each flow packet. The Derived Rule is NOT limited to a number. SCHC C/D Rule Manager decides when to create a new Derived Rule or delete it. At the end of the flow, SCHC MUST delete all the Derived Rules.¶
Figure 1 Shows the format of a Rule with Derivable Action.¶
Rule 1000 Action: Derivable +----------------+--+--+--+--------+--------+-----------++------+ | FID |FL|FP|DI| TV | MO | CDA || Sent | | | | | | | | ||[bits]| +----------------+--+--+--+--------+--------------------++------+ |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | | ... || | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | | ... | | | | | | || | |TCP Seq-Num. |32|1 |Up| 234 | LSB | MSB || XXX | +================+==+==+==+========+========+===========++======+ Rule 1001 Action: Derivable +----------------+--+--+--+--------+--------+-----------++------+ | FID |FL|FP|DI| TV | MO | CDA || Sent | | | | | | | | ||[bits]| +----------------+--+--+--+--------+--------------------++------+ |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | | ... || | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | | ... | | | | | | || | |TCP Seq-Num. |32|1 |Up| 235 | LSB | MSB || X | +================+==+==+==+========+========+===========++======+
The [RFC8724] defines the format of the Rule and its content. But it does not specify the different types of Rules. This document specifies two kinds of Rules for compressing the headers of a flow packet. Based-Rule and Derived-Rule.¶
A Based-Rule is a Rule as described in section 7.1 of RFC8724. These Rules are charged at run-time and contain the first values of the flow headers. But it will have the action Derivable.¶
A Derived-Rule is a short-life updated copy of a Based-Rule. This new Derived Rule has updated TV values of those fields that define the flow as Sequence Number, Timestamp, and any other field describing the flow. The compressor/decompressor will prioritize the last Derived Rule to compress the packet. And when needed, it can create another Derived Rule with new TV values or delete the oldest.¶
The Rule ID used to identify the Derived Rules is a complementary number of the Based Rule, so if the Based Rule has a 1000 RuleID, the Derived Rule will use 1001, ..., 1020,...¶
At the end of the flow transmission, SCHC must delete all the Derived Rules.¶
This document has no IANA actions.¶
This document does not add any security considerations and follows the [RFC8724].¶
To Do, examples.¶
The authors would like to thank (in alphabetic order): ToDo¶