]> Institut MINES TELECOM; IMT-Atlantique

2 rue de la Chataigneraie 35576 Cesson-Sevigne Cedex France Laurent.Toutain@imt-atlantique.fr

Consultant

Rue de Rennes 35510 Cesson-Sevigne Cedex France anaminaburo@gmail.com

Internet SCHC Working Group Internet-Draft This document describes how to compress the header of packets belonging to a flow using Static Context Header Compression and Fragmentation (SCHC) specifications.

Introduction This document defines how to use Static Context Header Compression and fragmentation (SCHC) and 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.

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

Terminology This document will follow the terms defined in and in . Rule. Part of the Context that describes how a packet is Compressed/Decompressed or Fragmented/Reassembled. Rule Manager (RM). It is in charge of handling data derived from the YANG Data Model and apply changes to the rules context. Action. Indication in the Rule to perform some operations. * To Do

Flow Compression This document does not change the way SCHC compresses and chooses a Rule. The behavior defined in 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.

## Action Derivable 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. Shows the format of a Rule with Derivable Action.

Type of Rules The 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.

Based-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.

Derived-Rule. 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.

IANA considerations This document has no IANA actions.

Security considerations This document does not add any security considerations and follows the .

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. 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. This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.

Appendix A To Do, examples.

Acknowledgements The authors would like to thank (in alphabetic order): ToDo