idnits 2.17.1 draft-ietf-6lo-paging-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: ---------------------------------------------------------------------------- == 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 14, 2016) is 3025 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) == Missing Reference: 'RFCthis' is mentioned on line 188, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' Summary: 0 errors (**), 0 flaws (~~), 3 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 14, 2016 5 Intended status: Standards Track 6 Expires: July 17, 2016 8 6LoWPAN Paging Dispatch 9 draft-ietf-6lo-paging-dispatch-00 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Page 1 Paging Dispatch . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 8.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The design of Low Power and Lossy Networks (LLNs) is generally 66 focused on saving energy, a very constrained resource in most cases. 67 The other constraints, such as the memory capacity and the duty 68 cycling of the LLN devices, derive from that primary concern. Energy 69 is often available from primary batteries that are expected to last 70 for years, or is scavenged from the environment in very limited 71 quantities. Any protocol that is intended for use in LLNs must be 72 designed with the primary concern of saving energy as a strict 73 requirement. 75 Controlling the amount of data transmission is one possible venue to 76 save energy. In a number of LLN standards, the frame size is limited 77 to much smaller values than the IPv6 maximum transmission unit (MTU) 78 of 1280 bytes. In particular, an LLN that relies on the classical 79 Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is limited to 127 80 bytes per frame. The need to compress IPv6 packets over IEEE 81 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work 82 (6LoWPAN-HC). 84 As more and more protocols need to be compressed, the encoding 85 capabilities of the original dispatch defined in the 6lo adaptation 86 layer framework ([RFC4944],[RFC6282]) becomes saturated. This 87 specification introduces a new context switch mechanism for 6LoWPAN 88 compression, expressed in terms of Pages and signaled by a new Paging 89 Dispatch. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 The Terminology used in this document is consistent with and 99 incorporates that described in `Terminology in Low power And Lossy 100 Networks' [RFC7102] and [RFC7228]. 102 3. Updating RFC 4944 104 This draft adapts 6LoWPAN while maintaining backward compatibility 105 with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of 106 "context" in the 6LoWPAN parser, a context being identified by a Page 107 number. This specification defines 16 Pages. 109 Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value 110 that indicates the next current Page. The Page number is encoded in 111 a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx 112 is the Page number, 0 to 15, as described in Figure 1: 114 0 115 0 1 2 3 4 5 6 7 116 +-+-+-+-+-+-+-+-+ 117 |1|1|1|1|Page Nb| 118 +-+-+-+-+-+-+-+-+ 120 Figure 1: Paging Dispatch with Page Number Encoding. 122 Values of the Dispatch byte defined in [RFC4944] are considered as 123 belonging to the Page 0 parsing context, which is the default and 124 does not need to be signaled explicitly at the beginning of a 6LoWPAN 125 packet. This ensures backward compatibility with existing 126 implementations of 6LoWPAN. 128 Note: This specification does not use the Escape Dispatch, which 129 extends Page 0 to more values, but rather allocates another Dispatch 130 Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in 131 all Pages, including Page 0 and Pages defined in future 132 specifications, to indicate the next parsing context represented by 133 its Page number. The rationale for avoiding that approach is that 134 there can be multiple occurrences of a new header indexed by this 135 specification in a single frame and the overhead on an octet each 136 time for the Escape Dispatch would be prohibitive. 138 A Page (say Page N) is is said to be active once the Page N Paging 139 Dispatch is parsed, and as long as no other Paging Dispatch is 140 parsed. 142 The Dispatch bits defined in Page 0 by [RFC4944] are free to be 143 reused in Pages 1 to 15. 145 4. Page 1 Paging Dispatch 147 This specification defines some special properties for Page 1, 148 detailed below: 150 The Dispatch bits defined in Page 0 for the Compression Format for 151 IPv6 Datagrams over IEEE 802.15.4-Based Networks [RFC6282] are 152 defined with the same values in Page 1 so there is no need to 153 switch context back from Page 1 to Page 0 to address LOWPAN_IPHC 154 and LOWPAN_NHC. 156 Mesh Headers represent Layer-2 information and are processed 157 before any Layer-3 information that is encoded in Page 1. If a 158 6LoWPAN packet requires a Mesh header, the Mesh Header MUST always 159 be placed in the packet before the first Page 1 Paging Dispatch, 160 if any. 162 For the same reason, Fragment Headers as defined in [RFC4944] MUST 163 always be placed in the packet before the first Page 1 Paging 164 Dispatch, if any. 166 The NALP Dispatch Bit Pattern as defined in [RFC4944] is only 167 defined for the first octet in the packet. Switching back to Page 168 0 for NALP inside a 6LoWPAN packet does not make sense. 170 parsing context after a context was switched to Page 1, so the 171 value for the Page 0 Paging Dispatch of 11110000 may not actually 172 be seen in packets following the 6LoWPAN specifications that are 173 available at the time of writing. 175 5. Security Considerations 177 The security considerations of [RFC4944] and [RFC6282] apply. 179 6. IANA Considerations 181 This document creates a IANA registry for the 6LoWPAN Routing Header 182 Type, and assigns the following values: 184 0..4 : RH3-6LoRH [RFCthis] 186 5 : RPI-6LoRH [RFCthis] 188 6 : IPinIP-6LoRH [RFCthis] 190 7. Acknowledgments 192 The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin 193 Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel 194 Montenegro and Ralph Droms for constructive reviews to the design in 195 the 6lo Working Group. 197 8. References 199 8.1. Normative References 201 [IEEE802154] 202 IEEE standard for Information Technology, "IEEE std. 203 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 204 and Physical Layer (PHY) Specifications for Low-Rate 205 Wireless Personal Area Networks", 2015. 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 213 "Transmission of IPv6 Packets over IEEE 802.15.4 214 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 215 . 217 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 218 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 219 DOI 10.17487/RFC6282, September 2011, 220 . 222 8.2. Informative References 224 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 225 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 226 2014, . 228 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 229 Constrained-Node Networks", RFC 7228, 230 DOI 10.17487/RFC7228, May 2014, 231 . 233 Author's Address 234 Pascal Thubert (editor) 235 Cisco Systems 236 Building D - Regus 237 45 Allee des Ormes 238 BP1200 239 MOUGINS - Sophia Antipolis 06254 240 FRANCE 242 Phone: +33 4 97 23 26 34 243 Email: pthubert@cisco.com