IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch
A page-number switch that gives 6LoWPAN header compression room to grow without breaking old devices.
Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>.
@misc{rfc8025,
series = {Request for Comments},
number = 8025,
howpublished = {RFC 8025},
publisher = {RFC Editor},
doi = {10.17487/RFC8025},
url = {https://www.rfc-editor.org/info/rfc8025},
author = {P. Thubert and R. Cragie},
title = {{IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch}},
pagetotal = 8,
year = 2016,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 8025 Cisco
Updates: 4944 R. Cragie
Category: Standards Track ARM
ISSN: 2070-1721 November 2016
IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Paging Dispatch
Abstract
This specification updates RFC 4944 to introduce a new context switch
mechanism for IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) compression, expressed in terms of Pages and signaled by a
new Paging Dispatch.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8025.
Copyright Notice
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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
The design of Low-Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is often a very constrained resource.
Other constraints, such as memory capacity and duty cycle
restrictions on LLN devices, usually derive from that primary
concern. Energy is often available only from primary batteries that
are expected to last for years or is scavenged from the environment
in very limited amounts. Any protocol that is intended for use in
LLNs must be designed with a primary focus on saving energy, which is
a strict requirement.
Controlling the amount of data transmission is one possible means of
saving energy. In a number of LLN standards, the frame size is
limited to much smaller values than the IPv6 maximum transmission
unit (MTU) of 1280 bytes. In particular, 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. The need to compress IPv6 packets
over IEEE 802.15.4 led to the 6LoWPAN Header Compression (6LoWPAN-HC)
[RFC6282] work.
As more and more protocols need to be compressed, the encoding
capabilities of the original dispatch defined in the 6LowPAN
adaptation-layer framework ([RFC4944] and [RFC6282]) becomes
saturated. This specification introduces a new context switch
mechanism for 6LoWPAN compression, 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 used in this document is consistent with and
incorporates that described in "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 maintaining backward compatibility
with IPv6 over IEEE 802.15.4 [RFC4944] by introducing the concept of
a "parsing context" in the 6LoWPAN parser, a context being identified
by a Page Number. This specification defines 16 Pages.
Pages are 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 described 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
Values of the Dispatch byte defined in [RFC4944] are considered as
belonging to the Page 0 parsing context, which is the default and
does not need to be signaled explicitly at the beginning of a 6LoWPAN
packet. This ensures backward compatibility with existing
implementations of 6LoWPAN.
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 whereas Page 15 is reserved for
Experimental Use [RFC5226].
Note: This specification does not use the Escape Dispatch, which
extends Page 0 to more values, but rather 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, to indicate the next parsing context represented by
its Page Number. The rationale for avoiding that approach is that
there can be multiple occurrences of a new header indexed by this
specification in a single frame and the overhead on an 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, and it remains active until another Paging
Dispatch is parsed.
4. Page 1 Paging Dispatch
This specification defines some special properties for Page 1,
detailed below:
The Dispatch bits defined for LOWPAN_IPHC by the "Compression
Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"
[RFC6282] are defined with the same values in Page 1, so there is
no need to switch context from Page 1 to Page 0 to decode a packet
that is encoded per [RFC6282].
Mesh Headers represent Layer 2 information and are processed
before any Layer 3 information that is 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 does not make sense.
As a result, there is 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.
5. Security Considerations
The security considerations of [RFC4944] and [RFC6282] apply.
6. IANA Considerations
6.1. Page Switch Dispatch Types
This document allocates 16 values for "Page switch" from the
"Dispatch Type Field" registry that was created by [RFC4944]. The
allocated values are from 11 110000 through 11 111111 and represent
Page Numbers 0 through 15 as discussed in this document.
6.2. New Column in Dispatch Type Registry
This document extends the "Dispatch Type Field" registry, which was
created by [RFC4944] and updated by [RFC6282], by adding a new column
called "Page".
This document defines 16 Pages, "Page 0" to "Page 15".
The preexisting registry content is assigned to "Page 0".
This document also associates the Dispatch type field values that are
allocated for LOWPAN_IPHC by [RFC6282] to Page 1. These values range
from 01 100000 through 01 111111 and have the same definition in Page
1 as they do in Page 0; as a result, Page 0 and Page 1 are grouped
together in the registry for this range.
Values ranging from 00 000000 to 11 101111 in Page 15 (that is, all
of Page 15 except the space used for Page switch) are reserved for
Experimental Use [RFC5226] and shall not be assigned.
Figure 2 represents the updates to the registry as described above.
Refer to <http://www.iana.org/assignments/_6lowpan-parameters> for
the complete list of updates.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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]. It is
expected that this policy will allow for other (non-IETF)
organizations to more easily obtain assignments.
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
AI ELI5
On this page
§1Why 6LoWPAN Needs Paging
Low-Power and Lossy Networks (LLNs) are designed first of all to save energy, because devices often run on primary batteries that must last for years or on very small amounts of scavenged energy. Sending less data is one way to save energy.
Frames in many LLN standards are far smaller than the IPv6 maximum transmission unit of 1280 bytes. A network using the classical physical layer of IEEE 802.15.4 is limited to 127 bytes per frame, which is why compressing IPv6 packets led to the 6LoWPAN Header Compression work in RFC 6282.
As more protocols need compression, the encoding capacity of the original dispatch defined in RFC 4944 and RFC 6282 becomes saturated. This RFC adds a context switch mechanism, expressed as Pages and signaled by a new Paging Dispatch.
A small gadget can only send a few bytes at a time, so it uses short codes. The list of short codes was nearly full, so this RFC finds a way to make more.
§2Pages as Parsing Contexts
The RFC adds the idea of a parsing context to the 6LoWPAN parser, where each context is identified by a Page Number. It defines 16 Pages.
Pages are delimited inside a packet by a Paging Dispatch value that names the next current Page. A Page N becomes active once its Paging Dispatch is parsed, and it stays active until another Paging Dispatch is parsed.
The dispatch values defined in RFC 4944 belong to Page 0. Page 0 is the default and does not need to be signaled at the start of a packet, which keeps existing implementations working. Those same Dispatch bits are free to be reused in Pages 1 to 15.
Think of a code book with 16 pages. Every message starts on page 0, so old readers know what to do. A special note can say turn to page 1, and from then on the same short codes mean new things.
§3The Paging Dispatch Byte
A Paging Dispatch is one byte with the bit pattern 11 11xxxx, where xxxx is the Page Number from 0 to 15. That uses the values 11 110000 through 11 111111.
The RFC does not use the Escape Dispatch, which would extend Page 0 to more values. A single packet can hold several occurrences of a new header indexed by this specification, and spending an extra octet on an Escape Dispatch each time would be prohibitive. The Paging Dispatch is instead present in all Pages, including Page 0 and Pages defined later.
The page note is one byte. The first four bits say this is a page note, and the last four bits give the page number, from 0 to 15.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PATTERN | Pattern | 4 bits | 1111 | Bit pattern 1111 that marks a Paging Dispatch. |
PAGE-NB | Page Nb | 4 bits | The Page Number, 0 to 15, that becomes the active parsing context. |
§4Page 1 and Backward Compatibility
Page 1 has special properties. The dispatch bits defined for LOWPAN_IPHC in RFC 6282 have the same values in Page 1, so a packet encoded per RFC 6282 can be decoded without switching from Page 1 back to Page 0.
Mesh Headers carry Layer 2 information and are processed before Layer 3 information encoded in Page 1. If a packet needs a Mesh Header, it MUST be placed before the first Page 1 Paging Dispatch, if any. Fragment Headers from RFC 4944 have the same requirement.
The NALP dispatch pattern is only defined for the first octet of a packet, so switching back to Page 0 for NALP inside a packet makes no sense. As a result, the Page 0 Paging Dispatch 11 110000 may not actually occur in packets that follow the 6LoWPAN specifications available when the RFC was written.
Page 1 keeps the old shorthand codes, so nothing needs to change for packets that already work. Some older notes, like routing and chopping-up labels, must come before the page-turn.
§5Registry Changes
IANA allocates 16 values for Page switch from the Dispatch Type Field registry created by RFC 4944, from 11 110000 through 11 111111, representing Page Numbers 0 through 15.
The registry also gets a new column called Page. Existing content is assigned to Page 0. The LOWPAN_IPHC values, 01 100000 through 01 111111, have the same definition in Page 1 as in Page 0, so Pages 0 and 1 are grouped together for that range.
Values in Page 15 from 00 000000 to 11 101111, which is everything except the Page switch space, are reserved for Experimental Use and shall not be assigned. Pages 1 to 14 are to be assigned for new protocols. Future assignments follow the Specification Required policy, which is expected to make it easier for non-IETF organizations to obtain assignments.
The official list of codes gets a new column for the page number. Old codes go on page 0, page 15 is kept for experiments, and the pages in between are saved for later.
| Page | Role |
|---|---|
| 0 | Default. Holds the RFC 4944 dispatch values and needs no explicit signal. |
| 1 THIS RFC | LOWPAN_IPHC values from RFC 6282 keep the same definition; more values made available for new protocols. |
| 2 to 14 | Values made available for new protocols; unassigned. |
| 15 | Reserved for Experimental Use, except the space used for Page switch. |
§6Security Considerations
The RFC adds nothing of its own here. It says only that the security considerations of RFC 4944 and RFC 6282 apply.
This change adds no new safety rules. The safety rules from the earlier documents still apply.