RFC 8025

IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch

📅 published November 2016, from ietf

RFC 8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch 🦋

Okay bestie, this one is Part 1 of 2 and it's a standards-track spec from the IETF. Two authors wrote it: P. Thubert (editor, from Cisco) and R. Cragie (from ARM). It was published in November 2016, it's a Standards Track document, and it's ISSN 2070-1721. The big headline is that it updates RFC 4944 💅. The header doesn't list anything it obsoletes.

Abstract ✨

Here's the whole vibe in one breath 🌸: this spec updates RFC 4944 and adds a brand new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression. The switch is expressed in terms of Pages and gets signaled by a new Paging Dispatch.

Status of This Memo

Real talk, this is an Internet Standards Track document 🎀.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want the deets on Internet Standards, check out Section 2 of RFC 7841.

Info about the current status, any errata, and where to send feedback lives at http://www.rfc-editor.org/info/rfc8025 🔗.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . .   3
4.  Page 1 Paging Dispatch  . . . . . . . . . . . . . . . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
  6.1.  Page Switch Dispatch Types  . . . . . . . . . . . . . . .   5
  6.2.  New Column in Dispatch Type Registry  . . . . . . . . . .   5
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 💖

Okay so the whole point of Low-Power and Lossy Networks (LLNs) is saving energy 🔋, because energy is usually the scarcest resource. Other limits, like memory capacity and duty cycle restrictions on LLN devices, mostly come from that main concern. The energy often comes from primary batteries that are supposed to last for years, or it's scavenged from the environment in tiny amounts. So any protocol meant for LLNs has to be designed with a primary focus on saving energy. That's a strict requirement, no cap.

Controlling how much data gets transmitted is one way to save energy 🦋. In a bunch of LLN standards the frame size is way smaller than the IPv6 maximum transmission unit (MTU) of 1280 bytes. For example, an LLN that relies on the classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE.802.15.4] is limited to 127 bytes per frame. So compressing IPv6 packets over IEEE 802.15.4 is what led to the 6LoWPAN Header Compression (6LoWPAN-HC) [RFC6282] work 🎀.

As more and more protocols need compressing, the encoding space of the original dispatch from the 6LowPAN adaptation-layer framework ([RFC4944] and [RFC6282]) gets saturated 😭. So this specification brings in a new context switch mechanism for 6LoWPAN compression. It's expressed in terms of Pages and signaled by a new Paging Dispatch mechanism ✨.

2. Terminology 🌸

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

The terminology here is consistent with, and builds on, "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102] and "Terminology for Constrained-Node Networks" [RFC7228] 🧠.

3. Updating RFC 4944 🔥

This document adapts 6LoWPAN while keeping backward compatibility with IPv6 over IEEE 802.15.4 [RFC4944]. How? It introduces the concept of a "parsing context" in the 6LoWPAN parser, and each context is identified by a Page Number. This specification defines 16 Pages 👑.

Pages get delimited in a 6LoWPAN packet by a Paging Dispatch value that indicates the next current Page. The Page Number is encoded in a Paging Dispatch with the Value Bit Pattern of 11 11xxxx, where xxxx is the Page Number, 0 to 15, as shown in Figure 1 🍓:

                            0
                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |1|1|1|1|Page Nb|
                           +-+-+-+-+-+-+-+-+

Figure 1: Paging Dispatch with Page Number Encoding

The Dispatch byte values defined in [RFC4944] count as belonging to the Page 0 parsing context. That's the default, so it doesn't need to be signaled explicitly at the beginning of a 6LoWPAN packet. This keeps existing 6LoWPAN implementations backward compatible 🫶.

The Dispatch bits defined in [RFC4944] are used in Page 0 and are free to be reused in Pages 1 to 15. In Section 4, this specification allocates some values in Page 1 and leaves the rest open for future allocations 🦋.

Values made available by this specification in Pages 1 to 14 are to be assigned for new protocols. Page 15, on the other hand, is reserved for Experimental Use [RFC5226] 🧪.

Note: This specification does not use the Escape Dispatch, which extends Page 0 to more values. Instead, it allocates another Dispatch Bit Pattern (11 11xxxx) for a new Paging Dispatch that is present in all Pages, including Page 0 and Pages defined in future specifications. That Paging Dispatch indicates the next parsing context, represented by its Page Number. The reason for avoiding the Escape Dispatch is that a new header indexed by this specification can occur multiple times in a single frame, and paying an extra octet each time for the Escape Dispatch would be prohibitive 😤.

A Page (say Page N) is said to be active once the Page N Paging Dispatch is parsed. It stays active until another Paging Dispatch is parsed 💫.

4. Page 1 Paging Dispatch 🎀

This specification defines some special properties for Page 1, and they're detailed below 🧁:

  • The Dispatch bits defined for LOWPAN_IPHC by the "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282] have the same values in Page 1. So there's no need to switch context from Page 1 to Page 0 to decode a packet that's encoded per [RFC6282] 🙌.
  • Mesh Headers represent Layer 2 information and get processed before any Layer 3 information encoded in Page 1. If a 6LoWPAN packet requires a Mesh Header, the Mesh Header MUST always be placed in the packet before the first Page 1 Paging Dispatch, if any 🚫.
  • For the same reason, Fragment Headers as defined in [RFC4944] MUST always be placed in the packet before the first Page 1 Paging Dispatch, if any 🧩.
  • The NALP Dispatch Bit Pattern as defined in [RFC4944] is only defined for the first octet in the packet. Switching back to Page 0 for NALP inside a 6LoWPAN packet doesn't make sense 🙃.
  • As a result, there's no need to restore the Page 0 parsing context after a context was switched to Page 1. So the value for the Page 0 Paging Dispatch of 11 110000 may not actually occur in those packets that adhere to 6LoWPAN specifications available at the time of writing this specification 👀.

6.2. New Column in Dispatch Type Registry 💖

okay so this document is literally extending the "Dispatch Type Field" registry 🎀 that [RFC4944] made and [RFC6282] updated, and it's adding a brand new column called "Page". iconic behaviour, honestly 💅

This document defines 16 Pages, "Page 0" to "Page 15" 🌸

The preexisting registry content is assigned to "Page 0" 🍓

This document also links the Dispatch type field values that [RFC6282] allocated for LOWPAN_IPHC to Page 1 🧚 These values run from 01 100000 through 01 111111, and they mean the exact same thing in Page 1 as they do in Page 0. So Page 0 and Page 1 get grouped together in the registry for that range, which is so neat 🦋

Values from 00 000000 to 11 101111 in Page 15 (basically all of Page 15 except the space used for Page switch) are reserved for Experimental Use [RFC5226] and shall not be assigned. 🔥

Figure 2 shows all the updates to the registry we just talked about. For the full list of updates, check <http://www.iana.org/assignments/_6lowpan-parameters> 💜

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Bit Pattern  |    Page     | Header Type         |  Reference      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  NALP               |  RFC 4944,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  00 xxxxxx    |    1-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |     0       |  ESC                |  RFC 6282,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  01 000000    |    1-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |    0-1      |  LOWPAN_IPHC        |  RFC 6282,      |
 |               |             |                     |  this document  |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  01 1xxxxx    |    2-14     |  Unassigned         |                 |
 +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |               |    15       |  Reserved for       |  this document  |
 |               |             |  Experimental Use   |                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ...                   ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  11 11xxxx    |    0-15     |  Page switch        |  this document  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Integrating the New Page Column ✨

Future assignments in these registries are to be coordinated via IANA under the policy of "Specification Required" [RFC5226]. The authors expect this policy to make it easier for other (non-IETF) organizations to get assignments too 🌈

7. References

7.1. Normative References

[IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, <http://ieeexplore.ieee.org/document/7460875/>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.

7.2. Informative References

[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <http://www.rfc-editor.org/info/rfc7102>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.

Acknowledgments

The authors wish to thank Tom Phinney, Thomas Watteyne, Tengfei Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel Montenegro, and Ralph Droms for constructive reviews of the design in the 6lo working group 🫶

Authors' Addresses

Pascal Thubert (editor) Cisco Systems Building D - Regus 45 Allee des Ormes BP1200 Mougins - Sophia Antipolis 06254 France

Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com

Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom

Email: robert.cragie@gridmerge.com

📦 where this page comes from