idnits 2.17.1 draft-ietf-6lo-paging-dispatch-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2016) is 2752 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 4944 (if approved) R. Cragie 5 Intended status: Standards Track ARM 6 Expires: April 15, 2017 October 12, 2016 8 6LoWPAN Paging Dispatch 9 draft-ietf-6lo-paging-dispatch-05 11 Abstract 13 This specification updates RFC 4944 to introduce a new context switch 14 mechanism for 6LoWPAN compression, expressed in terms of Pages and 15 signaled by a new Paging Dispatch. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 15, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Page 1 Paging Dispatch . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 6.1. Consuming Dispatch Types . . . . . . . . . . . . . . . . 5 58 6.2. New Column in Dispatch Type Registry . . . . . . . . . . 5 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The design of Low Power and Lossy Networks (LLNs) is generally 68 focused on saving energy, which often is a very constrained resource. 69 Other constraints, such as memory capacity and duty cycle 70 restrictions on LLN devices, usually derive from that primary 71 concern. Energy is often available only from primary batteries that 72 are expected to last for years, or is scavenged from the environment 73 in very limited amounts. Any protocol that is intended for use in 74 LLNs must be designed with a primary focus on saving energy, which is 75 a strict requirement. 77 Controlling the amount of data transmission is one possible means of 78 saving energy. In a number of LLN standards, the frame size is 79 limited to much smaller values than the IPv6 maximum transmission 80 unit (MTU) of 1280 bytes. In particular, an LLN that relies on the 81 classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is 82 limited to 127 bytes per frame. The need to compress IPv6 packets 83 over IEEE 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] 84 work (6LoWPAN-HC). 86 As more and more protocols need to be compressed, the encoding 87 capabilities of the original dispatch defined in the 6lo adaptation 88 layer framework ([RFC4944],[RFC6282]) becomes saturated. This 89 specification introduces a new context switch mechanism for 6LoWPAN 90 compression, expressed in terms of Pages and signaled by a new Paging 91 Dispatch mechanism. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 [RFC2119]. 100 The Terminology used in this document is consistent with and 101 incorporates that described in Terms Used in Routing for Low-Power 102 and Lossy Networks [RFC7102] and Terminology for Constrained-Node 103 Networks [RFC7228]. 105 3. Updating RFC 4944 107 This draft adapts 6LoWPAN while maintaining backward compatibility 108 with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of a 109 "parsing context" in the 6LoWPAN parser, a context being identified 110 by a Page Number. This specification defines 16 Pages. 112 Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value 113 that indicates the next current Page. The Page Number is encoded in 114 a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx 115 is the Page Number, 0 to 15, as described in Figure 1: 117 0 118 0 1 2 3 4 5 6 7 119 +-+-+-+-+-+-+-+-+ 120 |1|1|1|1|Page Nb| 121 +-+-+-+-+-+-+-+-+ 123 Figure 1: Paging Dispatch with Page Number Encoding. 125 Values of the Dispatch byte defined in [RFC4944] are considered as 126 belonging to the Page 0 parsing context, which is the default and 127 does not need to be signaled explicitly at the beginning of a 6LoWPAN 128 packet. This ensures backward compatibility with existing 129 implementations of 6LoWPAN. 131 The Dispatch bits defined in Page 0 by [RFC4944] are free to be 132 reused in Pages 1 to 15. This specification allocates some values in 133 Page 1 in Section 4 and leaves the rest open for future allocations. 135 Values opened by this specification in Page 1 to 14 are to be 136 assigned for new protocols whereas Page 15 is reserved for 137 experimentations. 139 Note: This specification does not use the Escape Dispatch, which 140 extends Page 0 to more values, but rather allocates another Dispatch 141 Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in 142 all Pages, including Page 0 and Pages defined in future 143 specifications, to indicate the next parsing context represented by 144 its Page Number. The rationale for avoiding that approach is that 145 there can be multiple occurrences of a new header indexed by this 146 specification in a single frame and the overhead on an octet each 147 time for the Escape Dispatch would be prohibitive. 149 A Page (say Page N) is said to be active once the Page N Paging 150 Dispatch is parsed, and remains active until another Paging Dispatch 151 is parsed. 153 4. Page 1 Paging Dispatch 155 This specification defines some special properties for Page 1, 156 detailed below: 158 The Dispatch bits defined for LOWPAN_IPHC by the Compression 159 Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks 160 [RFC6282] are defined with the same values in Page 1 so there is 161 no need to switch context from Page 1 to Page 0 to decode a packet 162 that is encoded per [RFC6282]. 164 Mesh Headers represent Layer-2 information and are processed 165 before any Layer-3 information that is encoded in Page 1. If a 166 6LoWPAN packet requires a Mesh header, the Mesh Header MUST always 167 be placed in the packet before the first Page 1 Paging Dispatch, 168 if any. 170 For the same reason, Fragment Headers as defined in [RFC4944] MUST 171 always be placed in the packet before the first Page 1 Paging 172 Dispatch, if any. 174 The NALP Dispatch Bit Pattern as defined in [RFC4944] is only 175 defined for the first octet in the packet. Switching back to Page 176 0 for NALP inside a 6LoWPAN packet does not make sense. 178 As a result, there is no need for restoring the Page 0 parsing 179 context after a context was switched to Page 1, so the value for 180 the Page 0 Paging Dispatch of 11110000 may not actually occur in 181 those packets that adhere to 6LoWPAN specifications available at 182 the time of writing this specification. 184 5. Security Considerations 186 The security considerations of [RFC4944] and [RFC6282] apply. 188 6. IANA Considerations 190 6.1. Consuming Dispatch Types 192 This document allocates 16 values from the Dispatch type field 193 registry that was created for [RFC4944]. The allocated values are 194 from 11 110000 through 11 111111 and represent Page Numbers 0 through 195 15 as discussed in this document. 197 6.2. New Column in Dispatch Type Registry 199 This document extends the Dispatch type field registry that was 200 created for [RFC4944] and updated by the [RFC6282], by adding a new 201 column called "Page". 203 This document defines 16 Pages, "Page 0" to "Page 15". 205 The content of the incumbent registry is assigned to "Page 0". 207 This document also places in the registry associated to Page 1 the 208 Dispatch type field values that are allocated for LOWPAN_IPHC by 209 [RFC6282]. These values range from 01 100000 through 01 111111 and 210 have the same definition in Page 1 as they do in Page 0; as a result, 211 the registry entries for Page 0 and Page 1 are an exact overlap in 212 this range. 214 Values ranging from 00000000 to 11101111 in Page 15 (that is all of 215 Page 15 but the space used for Page switch) is reserved for 216 experimentations and shall not be assigned. 218 The resulting registry may be represented as a table as follow 219 (partial): 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Pattern | Page | Header Type | defining document | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 0 | NALP | RFC 4944 | 225 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 00xxxxxx | 1..14 | free | | 227 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | 228 | | 15 | reserved | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 0 | ESC | RFC 6282 | 231 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | 01000000 | 1..14 | free | | 233 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | 234 | | 15 | reserved | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ... ... 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 0..1 | LOWPAN_IPHC | RFC 6282 | 239 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | 011xxxxx | 2..14 | free | | 241 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | 242 | | 15 | reserved | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 ... ... 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | 1111xxxx | 0..15 | Page switch | This | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: Integrating the new Page column 251 Future assignments in these registries are to be coordinated via IANA 252 under the policy of "Specification Required" [RFC5226]. It is 253 expected that this policy will allow for other (non-IETF) 254 organizations to more easily obtain assignments. 256 7. Acknowledgments 258 The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei 259 Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan 260 Hui, Gabriel Montenegro and Ralph Droms for constructive reviews to 261 the design in the 6lo Working Group. 263 8. References 264 8.1. Normative References 266 [IEEE802154] 267 IEEE standard for Information Technology, "IEEE std. 268 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 269 and Physical Layer (PHY) Specifications for Low-Rate 270 Wireless Personal Area Networks". 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, 274 DOI 10.17487/RFC2119, March 1997, 275 . 277 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 278 "Transmission of IPv6 Packets over IEEE 802.15.4 279 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 280 . 282 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 283 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 284 DOI 10.17487/RFC5226, May 2008, 285 . 287 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 288 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 289 DOI 10.17487/RFC6282, September 2011, 290 . 292 8.2. Informative References 294 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 295 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 296 2014, . 298 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 299 Constrained-Node Networks", RFC 7228, 300 DOI 10.17487/RFC7228, May 2014, 301 . 303 Authors' Addresses 304 Pascal Thubert (editor) 305 Cisco Systems 306 Building D - Regus 307 45 Allee des Ormes 308 BP1200 309 MOUGINS - Sophia Antipolis 06254 310 FRANCE 312 Phone: +33 4 97 23 26 34 313 Email: pthubert@cisco.com 315 Robert Cragie 316 ARM Ltd. 317 110 Fulbourn Road 318 Cambridge CB1 9NJ 319 UK 321 Email: robert.cragie@gridmerge.com