6lo P. Thubert, Ed.
Internet-Draft Cisco
Updates: 4944 (if approved) R. Cragie
Intended status: Standards Track ARM
Expires: April 15, 2017 October 12, 2016

6LoWPAN Paging Dispatch


This specification updates RFC 4944 to introduce a new context switch mechanism for 6LoWPAN compression, expressed in terms of Pages and signaled by a new Paging Dispatch.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 15, 2017.

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

The design of Low Power and Lossy Networks (LLNs) is generally focused on saving energy, which often is 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 [IEEE802154] is limited to 127 bytes per frame. The need to compress IPv6 packets over IEEE 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work (6LoWPAN-HC).

As more and more protocols need to be compressed, the encoding capabilities of the original dispatch defined in the 6lo adaptation layer framework ([RFC4944],[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 draft adapts 6LoWPAN while maintaining backward compatibility with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a 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 1111xxxx where xxxx is the Page Number, 0 to 15, as described in Figure 1:

                         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 Page 0 by [RFC4944] are free to be reused in Pages 1 to 15. This specification allocates some values in Page 1 in Section 4 and leaves the rest open for future allocations.

Values opened by this specification in Page 1 to 14 are to be assigned for new protocols whereas Page 15 is reserved for experimentations.

Note: This specification does not use the Escape Dispatch, which extends Page 0 to more values, but rather allocates another Dispatch Bit Pattern (1111xxxx) 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 remains active until another Paging Dispatch is parsed.

4. Page 1 Paging Dispatch

This specification defines some special properties for Page 1, detailed below:

5. Security Considerations

The security considerations of [RFC4944] and [RFC6282] apply.

6. IANA Considerations

6.1. Consuming Dispatch Types

This document allocates 16 values from the Dispatch type field registry that was created for [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 that was created for [RFC4944] and updated by the [RFC6282], by adding a new column called "Page".

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

The content of the incumbent registry is assigned to "Page 0".

This document also places in the registry associated to Page 1 the Dispatch type field values that are allocated for LOWPAN_IPHC by [RFC6282]. 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, the registry entries for Page 0 and Page 1 are an exact overlap in this range.

Values ranging from 00000000 to 11101111 in Page 15 (that is all of Page 15 but the space used for Page switch) is reserved for experimentations and shall not be assigned.

|    Pattern    |    Page     | Header Type | defining document       |
|               |     0       |  NALP       |      RFC 4944           |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  00xxxxxx     |   1..14     |  free       |                         |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
|               |    15       |  reserved   |                         |
|               |     0       |  ESC        |      RFC 6282           |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  01000000     |   1..14     |  free       |                         |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
|               |    15       |  reserved   |                         |
                      ...                   ...
|               |   0..1      | LOWPAN_IPHC |      RFC 6282           |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  011xxxxx     |   2..14     |  free       |                         |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+       N/A               |
|               |    15       |  reserved   |                         |
                      ...                   ...
|  1111xxxx     |   0..15     | Page switch |        This             |

Figure 2: Integrating the new Page column

The resulting registry may be represented as a table as follow (partial):

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. 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 to the design in the 6lo Working Group.

8. References

8.1. Normative References

[IEEE802154] IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks"
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[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.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011.

8.2. Informative References

[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014.
[RFC7228] Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014.

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 UK EMail: robert.cragie@gridmerge.com