idnits 2.17.1 draft-ietf-6lo-paging-dispatch-04.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 7 form feeds but 9 pages 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 (September 9, 2016) is 2758 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 (~~), 2 warnings (==), 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: March 13, 2017 September 9, 2016 8 6LoWPAN Paging Dispatch 9 draft-ietf-6lo-paging-dispatch-04 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 March 13, 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 6 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 Note: This specification does not use the Escape Dispatch, which 136 extends Page 0 to more values, but rather allocates another Dispatch 137 Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in 138 all Pages, including Page 0 and Pages defined in future 139 specifications, to indicate the next parsing context represented by 140 its Page Number. The rationale for avoiding that approach is that 141 there can be multiple occurrences of a new header indexed by this 142 specification in a single frame and the overhead on an octet each 143 time for the Escape Dispatch would be prohibitive. 145 A Page (say Page N) is said to be active once the Page N Paging 146 Dispatch is parsed, and as long as no other Paging Dispatch is 147 parsed. 149 4. Page 1 Paging Dispatch 151 This specification defines some special properties for Page 1, 152 detailed below: 154 The Dispatch bits defined for LOWPAN_IPHC by the Compression 155 Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks 156 [RFC6282] are defined with the same values in Page 1 so there is 157 no need to switch context from Page 1 to Page 0 to decode a packet 158 that is encoded per [RFC6282]. 160 Mesh Headers represent Layer-2 information and are processed 161 before any Layer-3 information that is encoded in Page 1. If a 162 6LoWPAN packet requires a Mesh header, the Mesh Header MUST always 163 be placed in the packet before the first Page 1 Paging Dispatch, 164 if any. 166 For the same reason, Fragment Headers as defined in [RFC4944] MUST 167 always be placed in the packet before the first Page 1 Paging 168 Dispatch, if any. 170 The NALP Dispatch Bit Pattern as defined in [RFC4944] is only 171 defined for the first octet in the packet. Switching back to Page 172 0 for NALP inside a 6LoWPAN packet does not make sense. 174 parsing context after a context was switched to Page 1, so the 175 value for the Page 0 Paging Dispatch of 11110000 may not actually 176 occur in those packets that adhere to 6LoWPAN specifications 177 available at the time of writing this specification. 179 5. Security Considerations 181 The security considerations of [RFC4944] and [RFC6282] apply. 183 6. IANA Considerations 184 6.1. Consuming Dispatch Types 186 This document allocates 16 values from the Dispatch type field 187 registry that was created for [RFC4944]. The allocated values are 188 from 11 110000 through 11 111111 and represent Page Numbers 0 through 189 15 as discussed in this document. 191 6.2. New Column in Dispatch Type Registry 193 This document extends the Dispatch type field registry that was 194 created for [RFC4944] and updated by the [RFC6282], by adding a new 195 column called "Page". 197 This document defines 16 Pages, "Page 0" to "Page 15". 199 The content of the incumbent registry is assigned to "Page 0". 201 This document also places in the registry associated to Page 1 the 202 Dispatch type field values that are allocated for LOWPAN_IPHC by 203 [RFC6282]. These values range from 01 100000 through 01 111111 and 204 have the same definition in Page 1 as they do in Page 0; as a result, 205 the registry entries for Page 0 and Page 1 are an exact overlap in 206 this range. 208 The resulting registry may be represented as a table as follow 209 (partial): 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Pattern | Page | Header Type | defining document | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 0 | NALP | RFC 4944 | 215 + 00xxxxxx +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 1..15 | free | N/A | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 0 | ESC | RFC 6282 | 219 + 01000000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 1..15 | free | N/A | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 ... ... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 0..1 | LOWPAN_IPHC | RFC 6282 | 225 + 011xxxxx +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 2..15 | free | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 ... ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | 1111xxxx | 0..15 | Page switch | This | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: Integrating the new Page column 235 Future assignments in these registries are to be coordinated via IANA 236 under the policy of "Specification Required" [RFC5226]. It is 237 expected that this policy will allow for other (non-IETF) 238 organizations to more easily obtain assignments. 240 7. Acknowledgments 242 The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei 243 Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan 244 Hui, Gabriel Montenegro and Ralph Droms for constructive reviews to 245 the design in the 6lo Working Group. 247 8. References 249 8.1. Normative References 251 [IEEE802154] 252 IEEE standard for Information Technology, "IEEE std. 253 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 254 and Physical Layer (PHY) Specifications for Low-Rate 255 Wireless Personal Area Networks". 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 263 "Transmission of IPv6 Packets over IEEE 802.15.4 264 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 265 . 267 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 268 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 269 DOI 10.17487/RFC5226, May 2008, 270 . 272 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 273 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 274 DOI 10.17487/RFC6282, September 2011, 275 . 277 8.2. Informative References 279 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 280 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 281 2014, . 283 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 284 Constrained-Node Networks", RFC 7228, 285 DOI 10.17487/RFC7228, May 2014, 286 . 288 Authors' Addresses 290 Pascal Thubert (editor) 291 Cisco Systems 292 Building D - Regus 293 45 Allee des Ormes 294 BP1200 295 MOUGINS - Sophia Antipolis 06254 296 FRANCE 298 Phone: +33 4 97 23 26 34 299 Email: pthubert@cisco.com 300 Robert Cragie 301 ARM Ltd. 302 110 Fulbourn Road 303 Cambridge CB1 9NJ 304 UK 306 Email: robert.cragie@gridmerge.com