draft-ietf-6lo-paging-dispatch-05.txt   rfc8025.txt 
6lo P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Internet-Draft Cisco Request for Comments: 8025 Cisco
Updates: 4944 (if approved) R. Cragie Updates: 4944 R. Cragie
Intended status: Standards Track ARM Category: Standards Track ARM
Expires: April 15, 2017 October 12, 2016 ISSN: 2070-1721 November 2016
6LoWPAN Paging Dispatch IPv6 over Low-Power Wireless Personal Area
draft-ietf-6lo-paging-dispatch-05 Network (6LoWPAN) Paging Dispatch
Abstract Abstract
This specification updates RFC 4944 to introduce a new context switch This specification updates RFC 4944 to introduce a new context switch
mechanism for 6LoWPAN compression, expressed in terms of Pages and mechanism for IPv6 over Low-Power Wireless Personal Area Network
signaled by a new Paging Dispatch. (6LoWPAN) compression, expressed in terms of Pages and signaled by a
new Paging Dispatch.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on April 15, 2017. 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 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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6.1. Consuming Dispatch Types . . . . . . . . . . . . . . . . 5 6.1. Page Switch Dispatch Types . . . . . . . . . . . . . . . 5
6.2. New Column in Dispatch Type Registry . . . . . . . . . . 5 6.2. New Column in Dispatch Type Registry . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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, which often is a very constrained resource. focused on saving energy, which is often a very constrained resource.
Other constraints, such as memory capacity and duty cycle Other constraints, such as memory capacity and duty cycle
restrictions on LLN devices, usually derive from that primary restrictions on LLN devices, usually derive from that primary
concern. Energy is often available only from primary batteries that concern. Energy is often available only from primary batteries that
are expected to last for years, or is scavenged from the environment are expected to last for years or is scavenged from the environment
in very limited amounts. Any protocol that is intended for use in 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 LLNs must be designed with a primary focus on saving energy, which is
a strict requirement. a strict requirement.
Controlling the amount of data transmission is one possible means of Controlling the amount of data transmission is one possible means of
saving energy. In a number of LLN standards, the frame size is saving energy. In a number of LLN standards, the frame size is
limited to much smaller values than the IPv6 maximum transmission limited to much smaller values than the IPv6 maximum transmission
unit (MTU) of 1280 bytes. In particular, an LLN that relies on the unit (MTU) of 1280 bytes. In particular, an LLN that relies on the
classical Physical Layer (PHY) of IEEE 802.15.4 [IEEE802154] is 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 limited to 127 bytes per frame. The need to compress IPv6 packets
over IEEE 802.15.4 led to the 6LoWPAN Header Compression [RFC6282] over IEEE 802.15.4 led to the 6LoWPAN Header Compression (6LoWPAN-HC)
work (6LoWPAN-HC). [RFC6282] work.
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 6LowPAN
layer framework ([RFC4944],[RFC6282]) becomes saturated. This adaptation-layer framework ([RFC4944] and [RFC6282]) becomes
specification introduces a new context switch mechanism for 6LoWPAN saturated. This specification introduces a new context switch
compression, expressed in terms of Pages and signaled by a new Paging mechanism for 6LoWPAN compression, expressed in terms of Pages and
Dispatch mechanism. signaled by a new Paging 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 Terms Used in Routing for Low-Power incorporates that described in "Terms Used in Routing for Low-Power
and Lossy Networks [RFC7102] and Terminology for Constrained-Node and Lossy Networks" [RFC7102] and "Terminology for Constrained-Node
Networks [RFC7228]. Networks" [RFC7228].
3. Updating RFC 4944 3. Updating RFC 4944
This draft adapts 6LoWPAN while maintaining backward compatibility This document adapts 6LoWPAN while maintaining backward compatibility
with IPv6 over IEEE 802.15.4 [RFC4944] by introducing a concept of a with IPv6 over IEEE 802.15.4 [RFC4944] by introducing the concept of
"parsing context" in the 6LoWPAN parser, a context being identified a "parsing context" in the 6LoWPAN parser, a context being identified
by a Page 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 11 11xxxx, 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 The Dispatch bits defined in [RFC4944] are used in Page 0 and are
reused in Pages 1 to 15. This specification allocates some values in free to be reused in Pages 1 to 15. In Section 4, this specification
Page 1 in Section 4 and leaves the rest open for future allocations. allocates some values in Page 1 and leaves the rest open for future
allocations.
Values opened by this specification in Page 1 to 14 are to be Values made available by this specification in Pages 1 to 14 are to
assigned for new protocols whereas Page 15 is reserved for be assigned for new protocols whereas Page 15 is reserved for
experimentations. Experimental Use [RFC5226].
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 (11 11xxxx) 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 said to be active once the Page N Paging 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 Dispatch is parsed, and it remains active until another Paging
is parsed. Dispatch is parsed.
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 for LOWPAN_IPHC by the Compression The Dispatch bits defined for LOWPAN_IPHC by the "Compression
Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks"
[RFC6282] are defined with the same values in Page 1 so there is [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 no need to switch context from Page 1 to Page 0 to decode a packet
that is encoded per [RFC6282]. 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.
As a result, there is no need for restoring the Page 0 parsing 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 context after a context was switched to Page 1, so the value for
the Page 0 Paging Dispatch of 11110000 may not actually occur in the Page 0 Paging Dispatch of 11 110000 may not actually occur in
those packets that adhere to 6LoWPAN specifications available at those packets that adhere to 6LoWPAN specifications available at
the time of writing this specification. 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 6.1. Page Switch Dispatch Types
This document allocates 16 values from the Dispatch type field This document allocates 16 values for "Page switch" from the
registry that was created for [RFC4944]. The allocated values are "Dispatch Type Field" registry that was created by [RFC4944]. The
from 11 110000 through 11 111111 and represent Page Numbers 0 through allocated values are from 11 110000 through 11 111111 and represent
15 as discussed in this document. Page Numbers 0 through 15 as discussed in this document.
6.2. New Column in Dispatch Type Registry 6.2. New Column in Dispatch Type Registry
This document extends the Dispatch type field registry that was This document extends the "Dispatch Type Field" registry, which was
created for [RFC4944] and updated by the [RFC6282], by adding a new created by [RFC4944] and updated by [RFC6282], by adding a new column
column called "Page". called "Page".
This document defines 16 Pages, "Page 0" to "Page 15". This document defines 16 Pages, "Page 0" to "Page 15".
The content of the incumbent registry is assigned to "Page 0". The preexisting registry content is assigned to "Page 0".
This document also places in the registry associated to Page 1 the This document also associates the Dispatch type field values that are
Dispatch type field values that are allocated for LOWPAN_IPHC by allocated for LOWPAN_IPHC by [RFC6282] to Page 1. These values range
[RFC6282]. These values range from 01 100000 through 01 111111 and from 01 100000 through 01 111111 and have the same definition in Page
have the same definition in Page 1 as they do in Page 0; as a result, 1 as they do in Page 0; as a result, Page 0 and Page 1 are grouped
the registry entries for Page 0 and Page 1 are an exact overlap in together in the registry for this range.
this range.
Values ranging from 00000000 to 11101111 in Page 15 (that is all of Values ranging from 00 000000 to 11 101111 in Page 15 (that is, all
Page 15 but the space used for Page switch) is reserved for of Page 15 except the space used for Page switch) are reserved for
experimentations and shall not be assigned. Experimental Use [RFC5226] and shall not be assigned.
The resulting registry may be represented as a table as follow Figure 2 represents the updates to the registry as described above.
(partial): Refer to <http://www.iana.org/assignments/_6lowpan-parameters> for
the complete list of updates.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pattern | Page | Header Type | defining document | | Bit Pattern | Page | Header Type | Reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0 | NALP | RFC 4944 | | | 0 | NALP | RFC 4944, |
| | | | this document |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 00xxxxxx | 1..14 | free | | | 00 xxxxxx | 1-14 | Unassigned | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | 15 | reserved | | | | 15 | Reserved for | this document |
| | | Experimental Use | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0 | ESC | RFC 6282 | | | 0 | ESC | RFC 6282, |
| | | | this document |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 01000000 | 1..14 | free | | | 01 000000 | 1-14 | Unassigned | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | 15 | reserved | | | | 15 | Reserved for | this document |
| | | Experimental Use | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ... ... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0..1 | LOWPAN_IPHC | RFC 6282 | | | 0-1 | LOWPAN_IPHC | RFC 6282, |
| | | | this document |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 011xxxxx | 2..14 | free | | | 01 1xxxxx | 2-14 | Unassigned | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N/A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | 15 | reserved | | | | 15 | Reserved for | this document |
| | | Experimental Use | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ... ... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1111xxxx | 0..15 | Page switch | This | | 11 11xxxx | 0-15 | Page switch | this document |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Integrating the new Page column Figure 2: Integrating the New Page Column
Future assignments in these registries are to be coordinated via IANA Future assignments in these registries are to be coordinated via IANA
under the policy of "Specification Required" [RFC5226]. It is under the policy of "Specification Required" [RFC5226]. It is
expected that this policy will allow for other (non-IETF) expected that this policy will allow for other (non-IETF)
organizations to more easily obtain assignments. organizations to more easily obtain assignments.
7. Acknowledgments 7. References
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 7.1. Normative References
8.1. Normative References
[IEEE802154] [IEEE.802.15.4]
IEEE standard for Information Technology, "IEEE std. IEEE, "IEEE Standard for Low-Rate Wireless Networks",
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) IEEE 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
and Physical Layer (PHY) Specifications for Low-Rate <http://ieeexplore.ieee.org/document/7460875/>.
Wireless Personal Area Networks".
[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>.
[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>.
skipping to change at page 7, line 32 skipping to change at page 7, line 34
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[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>.
8.2. Informative References 7.2. Informative References
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>. 2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <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 Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems Cisco Systems
Building D - Regus Building D - Regus
45 Allee des Ormes 45 Allee des Ormes
BP1200 BP1200
MOUGINS - Sophia Antipolis 06254 Mougins - Sophia Antipolis 06254
FRANCE France
Phone: +33 4 97 23 26 34 Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Robert Cragie Robert Cragie
ARM Ltd. ARM Ltd.
110 Fulbourn Road 110 Fulbourn Road
Cambridge CB1 9NJ Cambridge CB1 9NJ
UK United Kingdom
Email: robert.cragie@gridmerge.com Email: robert.cragie@gridmerge.com
 End of changes. 50 change blocks. 
117 lines changed or deleted 123 lines changed or added

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