idnits 2.17.1 draft-ietf-6lo-paging-dispatch-01.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 5 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to mention this, which it should. 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 (January 15, 2016) is 2995 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 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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) January 15, 2016 5 Intended status: Standards Track 6 Expires: July 18, 2016 8 6LoWPAN Paging Dispatch 9 draft-ietf-6lo-paging-dispatch-01 11 Abstract 13 This specification introduces a new context switch mechanism for 14 6LoWPAN compression, expressed in terms of Pages and signaled by a 15 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 July 18, 2016. 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 Per-Page Dispatch Type registries . . . . . . . . . . 5 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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 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 Per-Page Dispatch Type registries 193 This document creates 15 new IANA registries for the Per-Page 194 Dispatch type fields, indexed by Page Number, 1 to 15. Each Registry 195 corresponds to a bit-field of one octet. 197 Future assignments in these registries are to be coordinated via IANA 198 under the policy of "Specification Required" [RFC2434]. It is 199 expected that this policy will allow for other (non-IETF) 200 organizations to more easily obtain assignments. 202 These registries extend the Dispatch type field registry that was 203 created for [RFC4944], which is considered as the registry for Page 204 0. 206 As described above, this document allocates in the registry 207 associated to Page 1 the Per-Page Dispatch type field values that are 208 allocated in the Dispatch type field for LOWPAN_IPHC by [RFC6282]. 209 Those values are from 01 100000 through 01 111111 and they have the 210 same definition in Page 1 as they do in Page 0, meaning that the 211 registries for Page 0 and Page 1 are an exact overlap in this range. 213 7. Acknowledgments 215 The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin 216 Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel 217 Montenegro and Ralph Droms for constructive reviews to the design in 218 the 6lo Working Group. 220 8. References 222 8.1. Normative References 224 [IEEE802154] 225 IEEE standard for Information Technology, "IEEE std. 226 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 227 and Physical Layer (PHY) Specifications for Low-Rate 228 Wireless Personal Area Networks", 2015. 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 236 IANA Considerations Section in RFCs", RFC 2434, 237 DOI 10.17487/RFC2434, October 1998, 238 . 240 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 241 "Transmission of IPv6 Packets over IEEE 802.15.4 242 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 243 . 245 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 246 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 247 DOI 10.17487/RFC6282, September 2011, 248 . 250 8.2. Informative References 252 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 253 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 254 2014, . 256 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 257 Constrained-Node Networks", RFC 7228, 258 DOI 10.17487/RFC7228, May 2014, 259 . 261 Author's Address 263 Pascal Thubert (editor) 264 Cisco Systems 265 Building D - Regus 266 45 Allee des Ormes 267 BP1200 268 MOUGINS - Sophia Antipolis 06254 269 FRANCE 271 Phone: +33 4 97 23 26 34 272 Email: pthubert@cisco.com