LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP
draft-toutain-lpwan-ipv6-static-context-hc-00

Document Type Replaced Internet-Draft (individual)
Last updated 2016-09-23
Replaced by draft-ietf-lpwan-ipv6-static-context-hc
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-ietf-lpwan-ipv6-static-context-hc
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-toutain-lpwan-ipv6-static-context-hc-00.txt

Abstract

This document describes a header compression scheme for IPv6, IPv6/ UDP based on static contexts. This technique is especially tailored for LPWA networks and could be extended to other protocol stacks. During the IETF history several compression mechanisms have been proposed. First mechanisms, such as RoHC, are using a context to store header field values and send smaller incremental differences on the link. Values in the context evolve dynamically with information contained in the compressed header. The challenge is to maintain sender's and receiver's contexts synchronized even with packet losses. Based on the fact that IPv6 contains only static fields, 6LoWPAN developed an efficient context-free compression mechanisms, allowing better flexibility and performance. The Static Context Header Compression (SCHC) combines the advantages of RoHC context which offers a great level of flexibility in the processing of fields, and 6LoWPAN behavior to elide fields that are known from the other side. Static context means that values in the context field do not change during the transmission, avoiding complex resynchronization mechanisms, incompatible with LPWA characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier. This document focuses on IPv6/UDP headers compression, but the mechanism can be applied to other protocols such as CoAP. It will be described in a separate document.

Authors

Ana Minaburo (ana@ackl.io)
Laurent Toutain (laurent.toutain@telecom-bretagne.eu)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)