Comparison of 6lo and SCHC
draft-toutain-6lo-6lo-and-schc-00

Document Type Active Internet-Draft (individual)
Last updated 2019-11-04
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
6lo Working Group                                            A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Standards Track                              L. Toutain
Expires: May 7, 2020              Institut MINES TELECOM; IMT Atlantique
                                                       November 04, 2019

                       Comparison of 6lo and SCHC
                   draft-toutain-6lo-6lo-and-schc-00

Abstract

   6lo and 6lowpan have standardized a stateless IPv6 and UDP
   compression method for mesh networks.  SCHC proposes a generic
   compression mechanism that can be applied to any protocol stack.  The
   lpwan working group is focusing on star topologies for IPv6, UDP and
   CoAP header compression and fragmentation.

   This document summarizes the differences between 6lo and SCHC and
   possible combination of SCHC and 6lo.

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 May 7, 2020.

Copyright Notice

   Copyright (c) 2019 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

Minaburo & Toutain         Expires May 7, 2020                  [Page 1]
Internet-Draft                6lo and SCHC                 November 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Comparison  . . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Stateless compression.  . . . . . . . . . . . . . . . . .   2
     2.2.  Meshed vs Star  . . . . . . . . . . . . . . . . . . . . .   2
     2.3.  Alignment . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Uniform vs specific compression rules.  . . . . . . . . . . .   3
     3.1.  Bitmap vs Rule ID . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Fragmentation . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Applicability of SCHC in a 6lo network. . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   6lo and 6lowpan have standardized a stateless IPv6 and UDP
   compression method for mesh networks.  SCHC proposes a generic
   compression mechanism that can be applied to any protocol stack.  The
   lpwan working group is focusing on star topologies for IPv6, UDP and
   CoAP header compression and fragmentation.

   This document summarizes the differences between 6lo and SCHC and
   possible combination of SCHC and 6lo.

2.  Comparison

2.1.  Stateless compression.

   Both compression protocols are stateless regarding the compression/
   decompression process.  Each packet is compressed and decompressed
   independently of the others and no information is stored during
   compression or decompression.

   The SCHC name comes from the fact that it is a generic mechanism and
   the context tells how to compress a specific packet.

2.2.  Meshed vs Star

   6lo is defined for meshed network therefore all the node must be able
   to manipulate any 6lo packet.

Minaburo & Toutain         Expires May 7, 2020                  [Page 2]
Internet-Draft                6lo and SCHC                 November 2019

   SCHC is defined for star network and compression is done at both
   ends.  SCHC offers the possibility to have different compression
   scheme for each branch of the star.  This scheme is described though
   a context.

   If SCHC had to be used in a mesh network, all the intermediary nodes
   will have to know the rules used in the network.

2.3.  Alignment

   6lo preserves alignment on bye boundary when sending header fields.
   SCHC is bit oriented and padding can be added when the packet is
   sent.

3.  Uniform vs specific compression rules.

   6lo focuses mainly on IPv6 header and predefine a compression scheme
   known by all the nodes in a 6lo network.

   SCHC defines a generic compression mechanism based on fields.  A
   field is an abstract notion.  A field has several properties:

   o  An ID identifying a specific field.

   o  A position when a field is repeated several times in a header.

   o  A length with can either be a size in bit or a function indicating
      how the size is computed.

   o  A direction which makes sense in a star topology since traffic is
      originating from a node or is for a node.

   The rule contains some functions:

   o  Matching Operator: this information is used to select candidate
      rules for compression.  A rule is selected if all the fields in
      the packets matches all the fields in the rule.  Current MO are:

      *  "ignore" (any value is possible),

      *  "equal",

      *  "MSB" (Most Significant Bits) or

      *  "Matching".

Minaburo & Toutain         Expires May 7, 2020                  [Page 3]
Internet-Draft                6lo and SCHC                 November 2019

   o  Compression Decompression Action: if a compression rule is
      selected, then compression action tells how to compress header
      fields into residues.  Current CDA are:

      *  Not-sent: the field is elided.  This behavior is found also in
         6lo as elided.

      *  Value-sent: the field is sent.  If the field was defined as
         variable, the length can be sent before the residue.  This
         behavior is found also in 6lo, but only for well-known length
         fields.

      *  LSB (Less Significant Bit): the less significant bits are sent.

      *  Matching-sent: an index is sent instead of the value. 6lo has
         something similar for hop-limit. 3 well-known values are
         defined.

3.1.  Bitmap vs Rule ID

   6lo defines a dispatch indicating the nature of the 6lo packet and
   for IPHC defines a bitmap to indicates the nature of the header
   compression.

   SCHC uses a rule ID to identify the nature of the SCHC packet.  Rule
   ID have a variable length, most frequent rules may use shorter
   values.  The rule ID space is split between compression and
   decompression rules.  The rule ID refers to a context which contains
   the nature of the rule and associated parameters.

   In a sense the combination dispatch and bitmap for compression are
   equivalent to the rule ID, the main difference is that the rules are
   implicit in 6lo and the same rules are shared by all the node and
   explicit in SCHC.  Context synchronization is needed between both
   ends.

3.2.  Fragmentation

   SCHC implement a fragmentation mechanisms dedicaded to LPWAN
   networks. 3 modes exists:

   o  NoAck mode is an optimisitc mode, a RCS (rassembly Check Sequence)
      is added in the last fragment. unvalid received messages are
      discarded.  No retransmission is done.

   o  Ack Always is base on a "jumping window", sender must received a
      acknowledgement to jump to the next window.

Minaburo & Toutain         Expires May 7, 2020                  [Page 4]
Internet-Draft                6lo and SCHC                 November 2019

   o  Ack on Error is more efficient.  The message is cut into tiles of
      a specific length.  Tiles are regrouped into windows.  Tiles are
      sent into fragments.  Fragment size may vary during transmission.
      Receiver generate

4.  Applicability of SCHC in a 6lo network.

   To apply SCHC in a 6lo meshed network, the following requirements are
   needed:

   o  A SCHC dispatch to indicate that a SCHC rule ID follows,

   o  A context synchronization among all the 6lo nodes to share the
      context, or predefined rules,

   o  The rule should not contain a direction indicator.

5.  Normative References

   [I-D.ietf-lpwan-ipv6-static-context-hc]
              Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
              Zuniga, "Static Context Header Compression (SCHC) and
              fragmentation for LPWAN, application to UDP/IPv6", draft-
              ietf-lpwan-ipv6-static-context-hc-22 (work in progress),
              October 2019.

   [rfc2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Ana Minaburo
   Acklio
   1137A avenue des Champs Blancs
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io

Minaburo & Toutain         Expires May 7, 2020                  [Page 5]
Internet-Draft                6lo and SCHC                 November 2019

   Laurent Toutain
   Institut MINES TELECOM; IMT Atlantique
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: Laurent.Toutain@imt-atlantique.fr

Minaburo & Toutain         Expires May 7, 2020                  [Page 6]