idnits 2.17.1 draft-gomez-6lo-schc-15dot4-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 abstract seems to contain references ([RFC6282], [RFC8724]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 10, 2021) is 1020 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Standards Track A. Minaburo 5 Expires: January 11, 2022 Acklio 6 July 10, 2021 8 Transmission of SCHC-compressed packets over IEEE 802.15.4 networks 9 draft-gomez-6lo-schc-15dot4-00 11 Abstract 13 A framework called Static Context Header Compression and 14 fragmentation (SCHC) has been designed with the primary goal of 15 supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies 16 [RFC8724]. One of the SCHC components is a header compression 17 mechanism. If used properly, SCHC header compression allows a 18 greater compression ratio than that achievable with traditional 19 6LoWPAN header compression [RFC6282]. For this reason, it may make 20 sense to use SCHC header compression in some 6LoWPAN environments, 21 including IEEE 802.15.4 networks. This document specifies how a 22 SCHC-compressed packet can be carried over IEEE 802.15.4 networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 11, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements language . . . . . . . . . . . . . . . . . . 3 61 2.2. Background on SCHC . . . . . . . . . . . . . . . . . . . 4 62 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Network topologies . . . . . . . . . . . . . . . . . . . 4 64 3.2. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4 65 4. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. SCHC Dispatch . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. SCHC compression for IPv6, UDP, and CoAP headers . . . . . . 6 69 6. Fragmentation and reassembly . . . . . . . . . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 10.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 RFC 6282 is the main specification for IPv6 over Low power Wireless 81 Personal Area Network (6LoWPAN) IPv6 header compression [RFC6282]. 82 This RFC was designed assuming IEEE 802.15.4 as the layer below the 83 6LoWPAN adaptation layer, and it has also been reused (with proper 84 adaptations) for IPv6 header compression over many other technologies 85 relatively similar to IEEE 802.15.4 in terms of characteristics such 86 as physical layer bit rate, layer 2 maximum payload size, etc. 87 Examples of such technologies comprise BLE, DECT-ULE, ITU G.9959, MS/ 88 TP, NFC, and PLC. RFC 6282 provides additional functionality, such 89 as a mechanism for UDP header compression. 91 In the best cases, RFC 6282 allows to compress a 40-byte IPv6 header 92 down to a 2-byte compressed header (for link-local interactions) or a 93 3-byte compressed header (when global IPv6 addresses are used). On 94 the other hand, an RFC 6282 compressed UDP header has a typical size 95 of 4 bytes. Therefore, in advantageous conditions, a 48-byte 96 uncompressed IPv6/UDP header may be compressed down to a 6-byte 97 format (when using link-local addresses) or a 7-byte format (for 98 global interactions) by using RFC 6282. 100 Recently, a framework called Static Context Header Compression (SCHC) 101 has been designed with the primary goal of supporting IPv6 over Low 102 Power Wide Area Network (LPWAN) technologies [RFC8724]. SCHC 103 comprises header compression and fragmentation functionality tailored 104 to the extraordinary constraints of LPWAN technologies, which are 105 more severe than those exhibited by IEEE 802.15.4 or other relatively 106 similar technologies. SCHC header compression allows a greater 107 compression ratio than that of RFC 6282. If used properly, SCHC 108 allows to compress an IPv6/UDP header down to e.g. a single byte. In 109 addition, SCHC can be used to compress Constrained Application 110 Protocol (CoAP) headers as well [RFC7252][RFC8824], which further 111 increases the achievable performance improvement of using SCHC header 112 compression, since there is no 6LoWPAN header compression defined for 113 CoAP. Therefore, it may make sense to use SCHC header compression in 114 some 6LoWPAN environments [I-D.toutain-6lo-6lo-and-schc], including 115 IEEE 802.15.4 networks, considering its greater efficiency. 117 If SCHC header compression is added to the panoply of header 118 compression mechanisms used in 6LoWPAN environments, then there is a 119 need to signal when a packet header has been compressed by using 120 SCHC. To this end, in its current form, the present document 121 specifies a 6LoWPAN Dispatch Type for SCHC header compression, based 122 on exploiting RFC 8025 Dispatch type space [RFC8025]. 124 This document specifies how a SCHC-compressed packet can be carried 125 over IEEE 802.15.4 networks. Note that, as per this document, and 126 while SCHC defines fragmentation mechanisms as well, 6LoWPAN/6Lo 127 fragmentation is used when necessary to transport SCHC-compressed 128 packets over IEEE 802.15.4 networks [RFC4944][RFC8931]. 130 TO-DO: indicate here any specific updates of RFC 8724 for IEEE 131 802.15.4. 133 2. Terminology 135 2.1. Requirements language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 BCP14 [RFC2119], [RFC8174], when, and only when, they appear in all 141 capitals, as shown here. 143 2.2. Background on SCHC 145 The reader is expected to be familiar with the terms and concepts 146 defined in the specification of SCHC (RFC 8724). 148 3. Architecture 150 3.1. Network topologies 152 IEEE 802.15.4 supports two main network topologies: the star 153 topology, and the peer-to-peer (i.e., mesh) topology. 155 SCHC has been designed for LPWAN technologies, which are typically 156 based on a star topology where constrained devices (e.g., sensors) 157 communicate with a less constrained, central network gateway [RFC 158 8376]. However, as stated in [draft-ietf-lpwan-architecture], SCHC 159 is generic and it can also be used in networking environments beyond 160 the ones originally considered for SCHC. 162 SCHC compression is applicable to both star topology and mesh 163 topology IEEE 802.15.4 networks. 165 3.2. Protocol stack 167 The traditional 6LoWPAN-based protocol stack for constrained devices 168 (Figure 1, left) places the 6LoWPAN adaptation layer between IPv6 and 169 an underlying technology such as IEEE 802.15.4. Suitable upper layer 170 protocols include CoAP [RFC7252] and UDP. (Note that, while CoAP has 171 also been specified over TCP, and TCP may play a significant role in 172 IoT environments [RFC9006], 6LoWPAN header compression has not been 173 defined for TCP.) 175 6LoWPAN can be envisioned as a set of two main sublayers, where the 176 upper one provides header compression, while the lower one offers 177 fragmentation. 179 This document defines an alternative approach for packet header 180 compression over IEEE 802.15.4, which leads to a modified protocol 181 stack (Figure 1, right). 183 +------------+ +------------+ 184 | CoAP, other| | CoAP, other| 185 +------------+ +------------+ 186 | UDP, other | | UDP, other | 187 +------------+ +------------+ 188 | IPv6 | | IPv6 | 189 +------------+ +------------+ 190 | 6LoWPAN HC | | SCHC HC | <-- NEW 191 +------------+ +------------+ 192 |6LoWPAN Frag| |6LoWPAN Frag| 193 +------------+ +------------+ 194 | 802.15.4 | | 802.15.4 | 195 +------------+ +------------+ 197 Figure 1: Traditional 6LoWPAN-based protocol stack over IEEE 802.15.4 198 (left) and alternative protocol stack using SCHC for header 199 compression (right). HC and Frag stand for Header Compression and 200 Fragmentation, respectively. 202 SCHC header compression may be applied to the headers of different 203 protocols or sets of protocols. Some examples include: i) IPv6 204 packet headers, ii) joint IPv6 and UDP packet headers, iii) joint 205 IPv6, UDP and CoAP packet headers, etc. 207 4. Frame Format 209 This document defines the frame format to be used when a SCHC- 210 compressed packet is carried over IEEE 802.15.4. Such format is 211 carried as IEEE 802.15.4 frame payload. The format comprises a SCHC 212 Dispatch Type, a SCHC Packet (i.e. a SCHC-compressed packet (RFC 213 8724), and Padding bits, if any). Figure 2 illustrates the described 214 frame format. 216 <---------- IEEE 802.15.4 frame payload ----------> 218 <----- SCHC Packet -----> 219 +---------------+-------------+---------+ - - - - + 220 | SCHC Dispatch | SCHC Header | Payload | Padding | 221 +---------------+-------------+---------+ - - - - + 223 Figure 2: Encapsulated, SCHC-compressed packet. Padding bits are 224 added if needed. 226 4.1. SCHC Dispatch 228 Adding SCHC header compression to the panoply of header compression 229 mechanisms used in 6LoWPAN/6Lo environments creates the need to 230 signal when a packet header has been compressed by using SCHC. To 231 this end, the present document specifies the SCHC Dispatch. The SCHC 232 Dispatch indicates that the next field in the frame format is a SCHC- 233 compressed header. The latter corresponds to a packet header that 234 has been compressed by using SCHC. As defined in [RFC8724], the SCHC 235 Header comprises a RuleID, and a compression residue. 237 This document defines the SCHC Dispatch as a 6LoWPAN Dispatch Type 238 for SCHC header compression, based on exploiting RFC 8025 Dispatch 239 type space and the concept of "pages" [RFC8025]. With the aim to 240 minimize overhead, the present document allocates a whole page (Page 241 2) for the SCHC Dispatch Type: 243 SCHC Dispatch Type bit pattern: 11110010 (Page 2) (Note: to be 244 confirmed by IANA)) 246 TO-DO: RuleID discussion 248 4.2. Padding 250 If SCHC header compression leads to a SCHC Packet size of a non- 251 integer number of bytes, padding bits of value equal to zero MUST be 252 appended to the SCHC Packet as appropriate to align to an octet 253 boundary. 255 5. SCHC compression for IPv6, UDP, and CoAP headers 257 SCHC header compression may be applied to the headers of different 258 protocols or sets of protocols. Some examples include: i) IPv6 259 packet headers, ii) joint IPv6 and UDP packet headers, iii) joint 260 IPv6, UDP and CoAP packet headers, etc. 262 IPv6 and UDP header fields MUST be compressed as per Section 10 of 263 RFC 8724. 265 TO-DO: adaptation of DevIID and AppIID in 802.15.4 environments 267 CoAP header fields MUST be compressed as per Sections 4 to 6 of RFC 268 8824. 270 TO-DO: provide examples for IPv6-only, IPv6/UDP and IPv6/UDP/CoAP. 272 6. Fragmentation and reassembly 274 After applying SCHC header compression to a packet intended for 275 transmission, if the size of the resulting frame format (Section 4) 276 exceeds the IEEE 802.15.4 frame payload space available, such frame 277 format MUST be fragmented, carried and reassembled by means of 278 6LoWPAN fragmentation and reassembly [RFC4944][RFC8931]. 280 7. IANA Considerations 282 This document requests the allocation of the Dispatch Type Field bit 283 pattern 11110010 (Page 2) as SCHC Dispatch Type. 285 8. Security Considerations 287 TBD 289 9. Acknowledgments 291 Ana Minaburo and Laurent Toutain suggested for the first time the use 292 of SCHC in environments where 6LoWPAN has traditionally been used. 293 Laurent Toutain made comments that helped shape this document. 295 Carles Gomez has been funded in part by the Spanish Government 296 through project PID2019-106808RA-I00, and by Secretaria 297 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 298 la Generalitat de Catalunya 2017 through grant SGR 376. 300 10. References 302 10.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, 306 DOI 10.17487/RFC2119, March 1997, 307 . 309 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 310 "Transmission of IPv6 Packets over IEEE 802.15.4 311 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 312 . 314 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 315 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 316 DOI 10.17487/RFC6282, September 2011, 317 . 319 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 320 Application Protocol (CoAP)", RFC 7252, 321 DOI 10.17487/RFC7252, June 2014, 322 . 324 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 325 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 326 RFC 8025, DOI 10.17487/RFC8025, November 2016, 327 . 329 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 330 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 331 May 2017, . 333 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 334 Zuniga, "SCHC: Generic Framework for Static Context Header 335 Compression and Fragmentation", RFC 8724, 336 DOI 10.17487/RFC8724, April 2020, 337 . 339 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 340 Context Header Compression (SCHC) for the Constrained 341 Application Protocol (CoAP)", RFC 8824, 342 DOI 10.17487/RFC8824, June 2021, 343 . 345 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 346 Area Network (6LoWPAN) Selective Fragment Recovery", 347 RFC 8931, DOI 10.17487/RFC8931, November 2020, 348 . 350 10.2. Informative References 352 [I-D.toutain-6lo-6lo-and-schc] 353 Minaburo, A. and L. Toutain, "Comparison of 6lo and SCHC", 354 draft-toutain-6lo-6lo-and-schc-00 (work in progress), 355 November 2019. 357 [RFC9006] Gomez, C., Crowcroft, J., and M. Scharf, "TCP Usage 358 Guidance in the Internet of Things (IoT)", RFC 9006, 359 DOI 10.17487/RFC9006, March 2021, 360 . 362 Authors' Addresses 363 Carles Gomez 364 UPC 365 C/Esteve Terradas, 7 366 Castelldefels 08860 367 Spain 369 Email: carlesgo@entel.upc.edu 371 Ana Minaburo 372 Acklio 373 1137A avenue des Champs Blancs 374 Cesson-Sevigne Cedex 35510 375 France 377 Email: ana@ackl.io