idnits 2.17.1 draft-martinez-lpwan-meshed-rules-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 March 2022) is 767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8724' is defined on line 139, but no explicit reference was found in the text == Unused Reference: 'RFC8824' is defined on line 145, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group I. Martinez 3 Internet-Draft L. Toutain 4 Intended status: Standards Track Institut MINES TELECOM; IMT Atlantique 5 Expires: 22 September 2022 21 March 2022 7 Can Rules be adapted to a Meshed environment 8 draft-martinez-lpwan-meshed-rules-00 10 Abstract 12 This document specifies how openSCHC handles the rule selection and 13 how this process can be extended to a meshed environment. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 22 September 2022. 32 Copyright Notice 34 Copyright (c) 2022 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Revised BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Revised BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Rule Manager . . . . . . . . . . . . . . . . . . . . . . . . 2 50 3. Extending the model . . . . . . . . . . . . . . . . . . . . . 3 51 4. Management with simple identified rules . . . . . . . . . . . 3 52 5. Management with double identified rules . . . . . . . . . . . 3 53 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 56 1. Introduction 58 This document specifies how openSCHC handles the rule selection and 59 how this process can be extended to a meshed environment. 61 2. Rule Manager 63 OpenSCHC imports rule in JSON, such has: 65 [{ 66 "DeviceID" : "udp:90.27.174.128:8888", 67 "SoR" : [ 68 { 69 "RuleID": 6, 70 "RuleIDLength": 3, 71 "Compression": [ 72 .... 74 Figure 1: Simple identified SoR. 76 A specific device may have several rules, identified in the SoR (Set 77 of Rules) key. The device is identified by a DeviceID. OpenSCHC 78 allows to send SCHC packet over an udp tunnel. In that case, the 79 device ID starts with the udp keyword, followed by the IP address and 80 the port number. 82 In that architecture, the core SCHC may contains several devices' 83 rules, idenfified by different ID. The device side contains only the 84 SoR associated to the device. 86 When a packet arrive to the SCHC core, a machting rule is searched 87 among all the rule. The core SCHC uses the device ID to effectively 88 send the SCHC packet to the device. 90 The device answers back to the core SCHC, ignoring the device ID 91 since this value identifies the device itself. 93 So, we can name core a SCHC instance containing rules that does not 94 contains its own ID and a device a SCHC instance containing rules 95 that contains only its own ID. Communication from device to core is 96 upstream and downstream in the reverse direction. 98 3. Extending the model 100 This example is defined for a star toplogy, and devices can send back 101 their response in case of UDP tunnel or use the media in case of 102 LPWAN. In a meshed network, several instances may coexist and use 103 the same ruleID for a device but the rule itself can be different. 105 The previous rule can be updated to add a CoreID: 107 [{ 108 "DeviceID" : "udp:90.27.174.128:8888", 109 "CoreID": "udp:123.1.2.3:23628" 110 "SoR" : [ 111 { 112 "RuleID": 6, 113 "RuleIDLength": 3, 114 "Compression": [ 115 .... 117 Figure 2: Double identified SoR. 119 The process for the core compression is the same. When the device 120 receives the SCHC packet, it identifies the coreID and select only 121 rules coming from this instance. When the devices sends a packet, 122 instead of replying on the same port. 124 4. Management with simple identified rules 126 A device receives a SCHC packet on a single idendified SoR, keeps 127 track of the sender to reply. This could be either the technology or 128 the address of the core. Only one core is allowed in that case. 130 5. Management with double identified rules 132 A device receiving a SCHC packet on a double identifie SoR, does not 133 have to keep track of the core address. When a packet needs to be 134 compressed, the selected rule indicates where to send the SCHC 135 packet. The device may have several SoR corresponding to each core. 137 6. Normative References 139 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 140 Zuniga, "SCHC: Generic Framework for Static Context Header 141 Compression and Fragmentation", RFC 8724, 142 DOI 10.17487/RFC8724, April 2020, 143 . 145 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 146 Context Header Compression (SCHC) for the Constrained 147 Application Protocol (CoAP)", RFC 8824, 148 DOI 10.17487/RFC8824, June 2021, 149 . 151 Authors' Addresses 153 Ivan Marino Martinez Bolivar 154 Institut MINES TELECOM; IMT Atlantique 155 2 rue de la Chataigneraie 156 CS 17607 157 35576 Cesson-Sevigne Cedex 158 France 159 Email: ivan-marino.martinez-bolivar@imt-atlantique.fr 161 Laurent Toutain 162 Institut MINES TELECOM; IMT Atlantique 163 2 rue de la Chataigneraie 164 CS 17607 165 35576 Cesson-Sevigne Cedex 166 France 167 Email: Laurent.Toutain@imt-atlantique.fr