idnits 2.17.1 draft-gomez-6lo-schc-dispatch-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.toutain-6lo-6lo-and-schc' is defined on line 240, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 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: Experimental July 13, 2020 5 Expires: January 14, 2021 7 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Dispatch 8 Type for SCHC 9 draft-gomez-6lo-schc-dispatch-00 11 Abstract 13 A new framework called Static Context Header Compression (SCHC) has 14 been designed to support IPv6 over Low Power Wide Area Network 15 (LPWAN) technologies [RFC8724]. One of the SCHC components is a 16 header compression mechanism. If used properly, SCHC header 17 compression allows a greater compression ratio than that achievable 18 with traditional 6LoWPAN header compression [RFC6282]. For this 19 reason, it may make sense to use SCHC header compression in some 20 6LoWPAN environments. In its current form, this document proposes a 21 number of 6LoWPAN Dispatch type approaches to signal when a packet 22 header has been compressed by using SCHC header compression. 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 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 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. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. SCHC Dispatch Type Approaches . . . . . . . . . . . . . . . . 3 62 4.1. Approach 1 . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Approach 2 . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.3. Approach 3 . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 RFC 6282 is the main specification for IPv6 over Low power Wireless 76 Personal Area Network (6LoWPAN) IPv6 header compression [RFC6282]. 77 This RFC was designed assuming IEEE 802.15.4 as the layer below the 78 6LoWPAN adaptation layer, and it has also been reused (with proper 79 adaptations) for IPv6 header compression over many other technologies 80 relatively similar to IEEE 802.15.4 in terms of characteristics such 81 as physical layer bit rate, layer 2 maximum payload size, etc. 82 Examples of such technologies comprise BLE, DECT-ULE, ITU G.9959, MS/ 83 TP, NFC, and PLC. RFC 6282 provides additional functionality, such 84 as a mechanism for UDP header compression. 86 In the best case, RFC 6282 allows to compress a 40-byte IPv6 header 87 down to a 2-byte compressed header (in link-local interactions) or a 88 3-byte compressed header (when global IPv6 addresses are used). On 89 the other hand, an RFC 6282 compressed UDP header has a typical size 90 of 4 bytes. Therefore, in advantageous conditions, a 48-byte 91 uncompressed IPv6/UDP header may be compressed down to a 7-byte 92 format by using RFC 6282. 94 Recently, a new framework called Static Context Header Compression 95 (SCHC) has been designed to support IPv6 over Low Power Wide Area 96 Network (LPWAN) technologies [RFC8724]. SCHC comprises header 97 compression and fragmentation functionality tailored to the 98 extraordinary constraints of LPWAN technologies, which are more 99 severe than those exhibited by IEEE 802.15.4 or other relatively 100 similar technologies. 102 SCHC header compression allows a greater compression ratio than that 103 of RFC 6282. If used properly, SCHC allows to compress an IPv6/UDP 104 header down to e.g. a single byte. Therefore, it may make sense to 105 use SCHC header compression in some 6LoWPAN environments [I- 106 D.toutain-6lo-6lo-and-schc], considering its greater efficiency. 108 If SCHC header compression is added to the panoply of header 109 compression mechanisms used in 6LoWPAN environments, then there is a 110 need to signal when a packet header has been compressed by using 111 SCHC. To this end, in its current form, the present document 112 proposes a number of 6LoWPAN Dispatch type approaches for SCHC header 113 compression, based on exploiting RFC 4944 and/or RFC 8025 Dispatch 114 type space [RFC4944][RFC8025]. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Frame Format 124 Figure 1 illustrates the content of an encapsulated, SCHC compressed, 125 IPv6 datagram: 127 +---------------+-------------+---------+ 128 | SCHC Dispatch | SCHC Header | Payload | 129 +---------------+-------------+---------+ 131 Figure 1: Encapsulated, SCHC compressed IPv6 datagram 133 The SCHC Header corresponds to a packet header that has been 134 compressed by using SCHC. As defined in [RFC8724], the SCHC Header 135 comprises a Rule ID, and a compression residue. (Note: more details, 136 including a discussion on padding, to be added.) 138 4. SCHC Dispatch Type Approaches 140 This section presents 3 different approaches for the SCHC Dispatch 141 type to be discussed. 143 4.1. Approach 1 145 A first approach for the SCHC Dispatch Pattern is using Not a LoWPAN 146 (NALP) Dispatch type space [RFC4944]. The first two bits in a NALP 147 Dispatch type are 00. Approach 1 defines that a Dispatch starting by 148 "001" indicates that a SCHC-compressed packet comes next. 150 SCHC Dispatch Pattern: 001XXXXX 152 The last 5 bits of the Dispatch (indicated as 'X' above) may be used 153 to define 32 different Rule IDs. 155 This approach has pros and cons. A single byte is used for the 156 Dispatch plus the Rule ID. However, is 32 a relatively low number of 157 possible Rule ID values? On the other hand, there may be backwards 158 compatibility issues with existing implementations, where SCHC- 159 compressed packets might be misunderstood as other types of packets. 161 4.2. Approach 2 163 A second approach, that also uses NALP Dispatch type space, is: 165 SCHC Dispatch Pattern: 001YYYYY YYYYYYYY 167 The last 13 bits of the Dispatch (indicated as 'Y' above) may be used 168 to define 8192 different Rule IDs. 170 With this approach, two bytes are used for the SCHC Dispatch plus the 171 Rule ID, but 8192 possible Rule IDs can be used. The same backwards 172 compatibility issues in Approach 1 may exist for Approach 2 as well. 174 4.3. Approach 3 176 A third approach, which is not based on using NALP space, is using 177 the RFC 8025 concept of "pages", which would allocate one page for 178 SCHC-compressed headers: 180 SCHC Dispatch Pattern: 1111ZZZZ (ZZZZ to be determined) 182 With this approach, and with the aim to minimize header overhead, a 183 whole page is allocated for the SCHC Dispatch type. A 1-byte Rule ID 184 follows the SCHC Dispatch Pattern. 186 In this case, two bytes are used for the SCHC Dispatch plus the Rule 187 ID. 256 possible Rule IDs can be used. There are no backwards 188 compatibility issues. 190 5. IANA Considerations 192 TBD 194 6. Security Considerations 196 TBD 198 7. Acknowledgments 200 Ana Minaburo and Laurent Toutain suggested for the first time the use 201 of SCHC in environments where 6LoWPAN has traditionally been used. 203 Carles Gomez has been funded in part by the Spanish Government 204 through project PID2019-106808RA-I00, and by Secretaria 205 d'Universitats i Recerca del Departament d'Empresa i Coneixement de 206 la Generalitat de Catalunya 2017 through grant SGR 376. 208 8. References 210 8.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 218 "Transmission of IPv6 Packets over IEEE 802.15.4 219 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 220 . 222 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 223 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 224 DOI 10.17487/RFC6282, September 2011, 225 . 227 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 228 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 229 RFC 8025, DOI 10.17487/RFC8025, November 2016, 230 . 232 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 233 Zuniga, "SCHC: Generic Framework for Static Context Header 234 Compression and Fragmentation", RFC 8724, 235 DOI 10.17487/RFC8724, April 2020, 236 . 238 8.2. Informative References 240 [I-D.toutain-6lo-6lo-and-schc] 241 Minaburo, A. and L. Toutain, "Comparison of 6lo and SCHC", 242 draft-toutain-6lo-6lo-and-schc-00 (work in progress), 243 November 2019. 245 Author's Address 247 Carles Gomez 248 UPC 249 C/Esteve Terradas, 7 250 Castelldefels 08860 251 Spain 253 Email: carlesgo@entel.upc.edu