idnits 2.17.1 draft-toutain-6lo-6lo-and-schc-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 (November 04, 2019) is 1628 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: 'I-D.ietf-lpwan-ipv6-static-context-hc' is defined on line 209, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-22 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Standards Track L. Toutain 5 Expires: May 7, 2020 Institut MINES TELECOM; IMT Atlantique 6 November 04, 2019 8 Comparison of 6lo and SCHC 9 draft-toutain-6lo-6lo-and-schc-00 11 Abstract 13 6lo and 6lowpan have standardized a stateless IPv6 and UDP 14 compression method for mesh networks. SCHC proposes a generic 15 compression mechanism that can be applied to any protocol stack. The 16 lpwan working group is focusing on star topologies for IPv6, UDP and 17 CoAP header compression and fragmentation. 19 This document summarizes the differences between 6lo and SCHC and 20 possible combination of SCHC and 6lo. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2.1. Stateless compression. . . . . . . . . . . . . . . . . . 2 59 2.2. Meshed vs Star . . . . . . . . . . . . . . . . . . . . . 2 60 2.3. Alignment . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Uniform vs specific compression rules. . . . . . . . . . . . 3 62 3.1. Bitmap vs Rule ID . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Applicability of SCHC in a 6lo network. . . . . . . . . . . . 5 65 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 6lo and 6lowpan have standardized a stateless IPv6 and UDP 71 compression method for mesh networks. SCHC proposes a generic 72 compression mechanism that can be applied to any protocol stack. The 73 lpwan working group is focusing on star topologies for IPv6, UDP and 74 CoAP header compression and fragmentation. 76 This document summarizes the differences between 6lo and SCHC and 77 possible combination of SCHC and 6lo. 79 2. Comparison 81 2.1. Stateless compression. 83 Both compression protocols are stateless regarding the compression/ 84 decompression process. Each packet is compressed and decompressed 85 independently of the others and no information is stored during 86 compression or decompression. 88 The SCHC name comes from the fact that it is a generic mechanism and 89 the context tells how to compress a specific packet. 91 2.2. Meshed vs Star 93 6lo is defined for meshed network therefore all the node must be able 94 to manipulate any 6lo packet. 96 SCHC is defined for star network and compression is done at both 97 ends. SCHC offers the possibility to have different compression 98 scheme for each branch of the star. This scheme is described though 99 a context. 101 If SCHC had to be used in a mesh network, all the intermediary nodes 102 will have to know the rules used in the network. 104 2.3. Alignment 106 6lo preserves alignment on bye boundary when sending header fields. 107 SCHC is bit oriented and padding can be added when the packet is 108 sent. 110 3. Uniform vs specific compression rules. 112 6lo focuses mainly on IPv6 header and predefine a compression scheme 113 known by all the nodes in a 6lo network. 115 SCHC defines a generic compression mechanism based on fields. A 116 field is an abstract notion. A field has several properties: 118 o An ID identifying a specific field. 120 o A position when a field is repeated several times in a header. 122 o A length with can either be a size in bit or a function indicating 123 how the size is computed. 125 o A direction which makes sense in a star topology since traffic is 126 originating from a node or is for a node. 128 The rule contains some functions: 130 o Matching Operator: this information is used to select candidate 131 rules for compression. A rule is selected if all the fields in 132 the packets matches all the fields in the rule. Current MO are: 134 * "ignore" (any value is possible), 136 * "equal", 138 * "MSB" (Most Significant Bits) or 140 * "Matching". 142 o Compression Decompression Action: if a compression rule is 143 selected, then compression action tells how to compress header 144 fields into residues. Current CDA are: 146 * Not-sent: the field is elided. This behavior is found also in 147 6lo as elided. 149 * Value-sent: the field is sent. If the field was defined as 150 variable, the length can be sent before the residue. This 151 behavior is found also in 6lo, but only for well-known length 152 fields. 154 * LSB (Less Significant Bit): the less significant bits are sent. 156 * Matching-sent: an index is sent instead of the value. 6lo has 157 something similar for hop-limit. 3 well-known values are 158 defined. 160 3.1. Bitmap vs Rule ID 162 6lo defines a dispatch indicating the nature of the 6lo packet and 163 for IPHC defines a bitmap to indicates the nature of the header 164 compression. 166 SCHC uses a rule ID to identify the nature of the SCHC packet. Rule 167 ID have a variable length, most frequent rules may use shorter 168 values. The rule ID space is split between compression and 169 decompression rules. The rule ID refers to a context which contains 170 the nature of the rule and associated parameters. 172 In a sense the combination dispatch and bitmap for compression are 173 equivalent to the rule ID, the main difference is that the rules are 174 implicit in 6lo and the same rules are shared by all the node and 175 explicit in SCHC. Context synchronization is needed between both 176 ends. 178 3.2. Fragmentation 180 SCHC implement a fragmentation mechanisms dedicaded to LPWAN 181 networks. 3 modes exists: 183 o NoAck mode is an optimisitc mode, a RCS (rassembly Check Sequence) 184 is added in the last fragment. unvalid received messages are 185 discarded. No retransmission is done. 187 o Ack Always is base on a "jumping window", sender must received a 188 acknowledgement to jump to the next window. 190 o Ack on Error is more efficient. The message is cut into tiles of 191 a specific length. Tiles are regrouped into windows. Tiles are 192 sent into fragments. Fragment size may vary during transmission. 193 Receiver generate 195 4. Applicability of SCHC in a 6lo network. 197 To apply SCHC in a 6lo meshed network, the following requirements are 198 needed: 200 o A SCHC dispatch to indicate that a SCHC rule ID follows, 202 o A context synchronization among all the 6lo nodes to share the 203 context, or predefined rules, 205 o The rule should not contain a direction indicator. 207 5. Normative References 209 [I-D.ietf-lpwan-ipv6-static-context-hc] 210 Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. 211 Zuniga, "Static Context Header Compression (SCHC) and 212 fragmentation for LPWAN, application to UDP/IPv6", draft- 213 ietf-lpwan-ipv6-static-context-hc-22 (work in progress), 214 October 2019. 216 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 Authors' Addresses 223 Ana Minaburo 224 Acklio 225 1137A avenue des Champs Blancs 226 35510 Cesson-Sevigne Cedex 227 France 229 Email: ana@ackl.io 230 Laurent Toutain 231 Institut MINES TELECOM; IMT Atlantique 232 2 rue de la Chataigneraie 233 CS 17607 234 35576 Cesson-Sevigne Cedex 235 France 237 Email: Laurent.Toutain@imt-atlantique.fr