Code Monkey home page Code Monkey logo

microschc's Introduction

microSCHC

In a nutshell

Implementation in microPython of SCHC as specified in RFC 8724 [1].

License

MIT License, Copyright (c) 2022 Orange, by Quentin Lampin

Installing microSCHC

Releases of microSCHC are available on PyPI. To install microSCHC, run

pip install microschc

Latest (pre-release) microSCHC versions can be built from source using hatch and installed using the wheel (.whl) file generated in the dist/ folder.

build:

hatch build -t wheel

installation:

pip install dist/microschc-<version>-py3-none-any.whl

microSCHC, developpement plan

microSCHC aims at implementing the SCHC Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) routines described in RFC 8724 [1].

The initial focus of this effort is on the Compression/Decompression (C/D) routines and parsers for typical IoT protocol stacks, i.e. based on IPv6 [2], UDP [3], CoAP [4], lwM2M.

Current features:

  1. Parsers

    • IPv4
    • IPv6
    • UDP
    • CoAP (partial test coverage: options missing)
    • CoAP over UDP over IPv6 stack parser
    • lwM2M ( when not using CoAP options, i.e. CoAP payloads) --> postponed to after full SCHC C/D implementation

  2. Matching Operators (MO)

    • equal
    • ignore
    • MSB(x)
    • match-mapping

  3. Compression/Decompression Actions (CDA)

    1. Compression

      • not-sent
      • value-sent
      • mapping-sent
      • LSB
      • compute-* (e.g. UDP-checksum)
      • devIID
      • AppIID

    2. Decompression counterparts

      • not-sent
      • value-sent
      • mapping-sent
      • LSB
      • [-] compute-* (e.g. UDP-checksum)
        • UDP Checksum
        • UDP Length
        • IPv6 Payload Length
        • IPv4 Payload Length
      • devIID
      • AppIID

  4. Rules

    • rule data model
    • rule matching algorithm
    • YANG model interpreter

  5. Compression

    • field (left-)packet
    • field residues concatenation
    • length of variable length field encoding
    • packet compression

  6. Context Management

    • Definition & implementation of custom SCHC Context (not specified in RFCs)
  • [1] "RFC 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation" , A. Minaburo et al.
  • [2] "RFC 8200 Internet Protocol, Version 6 (IPv6) Specification, S. Deering et al."
  • [3] "RFC 768 User Datagram Protocol, J. Postel"
  • [4] "RFC 7252 The Constrained Application Protocol (CoAP), Z. Shelby et al."

microschc's People

Contributors

quentinlampin avatar

Stargazers

avatar avatar avatar

Watchers

avatar avatar avatar avatar

Forkers

cbanier ghitark

microschc's Issues

Discussion: support of value types other than bytes (and integers)

Context

In RFC 8724, it is explained that field values types returned by the parser are not constrained and the choice is left to the implementer. In page 13, it is indeed stated:

Target Value (TV) is the value used to match against the packet header field. The Target Value can be a scalar value of any type (integer, strings, etc.) or a more complex structure (array, list, etc.). The types and representations are out of scope for this document.

Moreover, the Matching Operators MSB(x), described in section 7.3, implicitly mandates the support of a raw representation of the field values. In (micro)Python, the closest representation type is bytes, making it a default, de facto, type for parsers.

Supporting types other than bytes, e.g. integer, strings, arrays, is challenging because of encoding/decoding issues. Here is a list of issues that comes to mind:

  • Integers of arbitrary encoding, e.g. endianness
  • Arbitrary string encoding: e.g. utf-8, ascii, latin-*, etc.
  • Arrays encoding: e.g. array delimiters.

In general, unless the Compression/Decompression Actions (CDAs) keep track of the specific encoding of source (uncompressed) packets, the received (decompressed) packets may end up different from the source, leading to systematic transmission errors.

Assuming network ordering of bytes, the implementation can however get away without storing the encoding of integer fields, hence the "easy" support of integers.

The Question

In light of the encoding issues, should the implementation support other field types ? What would be the pros and cons ?

The issue is there to keep track of the thought process about this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.