Internet-Draft LPWAN SCHC Meshed rules March 2022
Martinez & Toutain Expires 22 September 2022 [Page]
Workgroup:
lpwan Working Group
Internet-Draft:
draft-martinez-lpwan-meshed-rules-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
I. Martinez
Institut MINES TELECOM; IMT Atlantique
L. Toutain
Institut MINES TELECOM; IMT Atlantique

Can Rules be adapted to a Meshed environment

Abstract

This document specifies how openSCHC handles the rule selection and how this process can be extended to a meshed environment.

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 22 September 2022.

1. Introduction

This document specifies how openSCHC handles the rule selection and how this process can be extended to a meshed environment.

2. Rule Manager

OpenSCHC imports rule in JSON, such has:

[{
    "DeviceID" : "udp:90.27.174.128:8888",
    "SoR" : [
         {
            "RuleID": 6,
            "RuleIDLength": 3,
            "Compression": [
            ....

Figure 1: Simple identified SoR.

A specific device may have several rules, identified in the SoR (Set of Rules) key. The device is identified by a DeviceID. OpenSCHC allows to send SCHC packet over an udp tunnel. In that case, the device ID starts with the udp keyword, followed by the IP address and the port number.

In that architecture, the core SCHC may contains several devices' rules, idenfified by different ID. The device side contains only the SoR associated to the device.

When a packet arrive to the SCHC core, a machting rule is searched among all the rule. The core SCHC uses the device ID to effectively send the SCHC packet to the device.

The device answers back to the core SCHC, ignoring the device ID since this value identifies the device itself.

So, we can name core a SCHC instance containing rules that does not contains its own ID and a device a SCHC instance containing rules that contains only its own ID. Communication from device to core is upstream and downstream in the reverse direction.

3. Extending the model

This example is defined for a star toplogy, and devices can send back their response in case of UDP tunnel or use the media in case of LPWAN. In a meshed network, several instances may coexist and use the same ruleID for a device but the rule itself can be different.

The previous rule can be updated to add a CoreID:

[{
    "DeviceID" : "udp:90.27.174.128:8888",
    "CoreID": "udp:123.1.2.3:23628"
    "SoR" : [
         {
            "RuleID": 6,
            "RuleIDLength": 3,
            "Compression": [
            ....

Figure 2: Double identified SoR.

The process for the core compression is the same. When the device receives the SCHC packet, it identifies the coreID and select only rules coming from this instance. When the devices sends a packet, instead of replying on the same port.

4. Management with simple identified rules

A device receives a SCHC packet on a single idendified SoR, keeps track of the sender to reply. This could be either the technology or the address of the core. Only one core is allowed in that case.

5. Management with double identified rules

A device receiving a SCHC packet on a double identifie SoR, does not have to keep track of the core address. When a packet needs to be compressed, the selected rule indicates where to send the SCHC packet. The device may have several SoR corresponding to each core.

6. Normative References

[RFC8724]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.
[RFC8824]
Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, , <https://www.rfc-editor.org/info/rfc8824>.

Authors' Addresses

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