draft-ietf-6lo-paging-dispatch-00.txt   draft-ietf-6lo-paging-dispatch-01.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 4944 (if approved) January 14, 2016 Updates: 4944 (if approved) January 15, 2016
Intended status: Standards Track Intended status: Standards Track
Expires: July 17, 2016 Expires: July 18, 2016
6LoWPAN Paging Dispatch 6LoWPAN Paging Dispatch
draft-ietf-6lo-paging-dispatch-00 draft-ietf-6lo-paging-dispatch-01
Abstract Abstract
This specification introduces a new context switch mechanism for This specification introduces a new context switch mechanism for
6LoWPAN compression, expressed in terms of Pages and signaled by a 6LoWPAN compression, expressed in terms of Pages and signaled by a
new Paging Dispatch. new Paging Dispatch.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line -133 skipping to change at page 1, line -137
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2016. This Internet-Draft will expire on July 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 3 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 3
4. Page 1 Paging Dispatch . . . . . . . . . . . . . . . . . . . 4 4. Page 1 Paging Dispatch . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6.1. Consuming Dispatch Types . . . . . . . . . . . . . . . . 5
6.2. New Per-Page Dispatch Type registries . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, a very constrained resource in most cases. focused on saving energy, which often is a very constrained resource.
The other constraints, such as the memory capacity and the duty Other constraints, such as memory capacity and duty cycle
cycling of the LLN devices, derive from that primary concern. Energy restrictions on LLN devices, usually derive from that primary
is often available from primary batteries that are expected to last concern. Energy is often available only from primary batteries that
for years, or is scavenged from the environment in very limited are expected to last for years, or is scavenged from the environment
quantities. Any protocol that is intended for use in LLNs must be in very limited amounts. Any protocol that is intended for use in
designed with the primary concern of saving energy as a strict LLNs must be designed with a primary focus on saving energy, which is
requirement. a strict requirement.
Controlling the amount of data transmission is one possible venue to Controlling the amount of data transmission is one possible means of
save energy. In a number of LLN standards, the frame size is limited saving energy. In a number of LLN standards, the frame size is
to much smaller values than the IPv6 maximum transmission unit (MTU) limited to much smaller values than the IPv6 maximum transmission
of 1280 bytes. In particular, an LLN that relies on the classical unit (MTU) of 1280 bytes. In particular, an LLN that relies on the
Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is limited to 127 classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is
bytes per frame. The need to compress IPv6 packets over IEEE limited to 127 bytes per frame. The need to compress IPv6 packets
802.15.4 led to the 6LoWPAN Header Compression [RFC6282] work over IEEE 802.15.4 led to the 6LoWPAN Header Compression [RFC6282]
(6LoWPAN-HC). work (6LoWPAN-HC).
As more and more protocols need to be compressed, the encoding As more and more protocols need to be compressed, the encoding
capabilities of the original dispatch defined in the 6lo adaptation capabilities of the original dispatch defined in the 6lo adaptation
layer framework ([RFC4944],[RFC6282]) becomes saturated. This layer framework ([RFC4944],[RFC6282]) becomes saturated. This
specification introduces a new context switch mechanism for 6LoWPAN specification introduces a new context switch mechanism for 6LoWPAN
compression, expressed in terms of Pages and signaled by a new Paging compression, expressed in terms of Pages and signaled by a new Paging
Dispatch. Dispatch mechanism.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The Terminology used in this document is consistent with and The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in Terms Used in Routing for Low-Power
Networks' [RFC7102] and [RFC7228]. and Lossy Networks [RFC7102] and Terminology for Constrained-Node
Networks [RFC7228].
3. Updating RFC 4944 3. Updating RFC 4944
This draft adapts 6LoWPAN while maintaining backward compatibility This draft adapts 6LoWPAN while maintaining backward compatibility
with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of a
"context" in the 6LoWPAN parser, a context being identified by a Page "parsing context" in the 6LoWPAN parser, a context being identified
number. This specification defines 16 Pages. by a Page Number. This specification defines 16 Pages.
Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value
that indicates the next current Page. The Page number is encoded in that indicates the next current Page. The Page Number is encoded in
a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx a Paging Dispatch with the Value Bit Pattern of 1111xxxx where xxxx
is the Page number, 0 to 15, as described in Figure 1: is the Page Number, 0 to 15, as described in Figure 1:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|1|1|1|Page Nb| |1|1|1|1|Page Nb|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: Paging Dispatch with Page Number Encoding. Figure 1: Paging Dispatch with Page Number Encoding.
Values of the Dispatch byte defined in [RFC4944] are considered as Values of the Dispatch byte defined in [RFC4944] are considered as
belonging to the Page 0 parsing context, which is the default and 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 does not need to be signaled explicitly at the beginning of a 6LoWPAN
packet. This ensures backward compatibility with existing packet. This ensures backward compatibility with existing
implementations of 6LoWPAN. 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.
Note: This specification does not use the Escape Dispatch, which Note: This specification does not use the Escape Dispatch, which
extends Page 0 to more values, but rather allocates another Dispatch extends Page 0 to more values, but rather allocates another Dispatch
Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in Bit Pattern (1111xxxx) for a new Paging Dispatch, that is present in
all Pages, including Page 0 and Pages defined in future all Pages, including Page 0 and Pages defined in future
specifications, to indicate the next parsing context represented by specifications, to indicate the next parsing context represented by
its Page number. The rationale for avoiding that approach is that its Page Number. The rationale for avoiding that approach is that
there can be multiple occurrences of a new header indexed by this there can be multiple occurrences of a new header indexed by this
specification in a single frame and the overhead on an octet each specification in a single frame and the overhead on an octet each
time for the Escape Dispatch would be prohibitive. time for the Escape Dispatch would be prohibitive.
A Page (say Page N) is is said to be active once the Page N Paging A Page (say Page N) is is said to be active once the Page N Paging
Dispatch is parsed, and as long as no other Paging Dispatch is Dispatch is parsed, and as long as no other Paging Dispatch is
parsed. parsed.
The Dispatch bits defined in Page 0 by [RFC4944] are free to be
reused in Pages 1 to 15.
4. Page 1 Paging Dispatch 4. Page 1 Paging Dispatch
This specification defines some special properties for Page 1, This specification defines some special properties for Page 1,
detailed below: detailed below:
The Dispatch bits defined in Page 0 for the Compression Format for The Dispatch bits defined for LOWPAN_IPHC by the Compression
IPv6 Datagrams over IEEE 802.15.4-Based Networks [RFC6282] are Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
defined with the same values in Page 1 so there is no need to [RFC6282] are defined with the same values in Page 1 so there is
switch context back from Page 1 to Page 0 to address LOWPAN_IPHC no need to switch context from Page 1 to Page 0 to decode a packet
and LOWPAN_NHC. that is encoded per [RFC6282].
Mesh Headers represent Layer-2 information and are processed Mesh Headers represent Layer-2 information and are processed
before any Layer-3 information that is encoded in Page 1. If a before any Layer-3 information that is encoded in Page 1. If a
6LoWPAN packet requires a Mesh header, the Mesh Header MUST always 6LoWPAN packet requires a Mesh header, the Mesh Header MUST always
be placed in the packet before the first Page 1 Paging Dispatch, be placed in the packet before the first Page 1 Paging Dispatch,
if any. if any.
For the same reason, Fragment Headers as defined in [RFC4944] MUST For the same reason, Fragment Headers as defined in [RFC4944] MUST
always be placed in the packet before the first Page 1 Paging always be placed in the packet before the first Page 1 Paging
Dispatch, if any. Dispatch, if any.
The NALP Dispatch Bit Pattern as defined in [RFC4944] is only The NALP Dispatch Bit Pattern as defined in [RFC4944] is only
defined for the first octet in the packet. Switching back to Page defined for the first octet in the packet. Switching back to Page
0 for NALP inside a 6LoWPAN packet does not make sense. 0 for NALP inside a 6LoWPAN packet does not make sense.
parsing context after a context was switched to Page 1, so the parsing context after a context was switched to Page 1, so the
value for the Page 0 Paging Dispatch of 11110000 may not actually value for the Page 0 Paging Dispatch of 11110000 may not actually
be seen in packets following the 6LoWPAN specifications that are occur in those packets that adhere to 6LoWPAN specifications
available at the time of writing. available at the time of writing this specification.
5. Security Considerations 5. Security Considerations
The security considerations of [RFC4944] and [RFC6282] apply. The security considerations of [RFC4944] and [RFC6282] apply.
6. IANA Considerations 6. IANA Considerations
6.1. Consuming Dispatch Types
This document creates a IANA registry for the 6LoWPAN Routing Header This document allocates 16 values from the Dispatch type field
Type, and assigns the following values: 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.
0..4 : RH3-6LoRH [RFCthis] 6.2. New Per-Page Dispatch Type registries
5 : RPI-6LoRH [RFCthis] This document creates 15 new IANA registries for the Per-Page
Dispatch type fields, indexed by Page Number, 1 to 15. Each Registry
corresponds to a bit-field of one octet.
6 : IPinIP-6LoRH [RFCthis] Future assignments in these registries are to be coordinated via IANA
under the policy of "Specification Required" [RFC2434]. It is
expected that this policy will allow for other (non-IETF)
organizations to more easily obtain assignments.
These registries extend the Dispatch type field registry that was
created for [RFC4944], which is considered as the registry for Page
0.
As described above, this document allocates in the registry
associated to Page 1 the Per-Page Dispatch type field values that are
allocated in the Dispatch type field for LOWPAN_IPHC by [RFC6282].
Those values are from 01 100000 through 01 111111 and they have the
same definition in Page 1 as they do in Page 0, meaning that the
registries for Page 0 and Page 1 are an exact overlap in this range.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin
Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel
Montenegro and Ralph Droms for constructive reviews to the design in Montenegro and Ralph Droms for constructive reviews to the design in
the 6lo Working Group. the 6lo Working Group.
8. References 8. References
skipping to change at page 5, line 27 skipping to change at page 6, line 10
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", 2015. Wireless Personal Area Networks", 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
DOI 10.17487/RFC2434, October 1998,
<http://www.rfc-editor.org/info/rfc2434>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc6282>.
 End of changes. 25 change blocks. 
47 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/