< draft-ietf-roll-routing-dispatch-02.txt   draft-ietf-roll-routing-dispatch-03.txt >
roll P. Thubert, Ed. roll P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: April 22, 2017 Uni Bremen TZI Expires: April 28, 2017 Uni Bremen TZI
L. Toutain L. Toutain
IMT-TELECOM Bretagne IMT-TELECOM Bretagne
R. Cragie R. Cragie
ARM ARM
October 19, 2016 October 25, 2016
6LoWPAN Routing Header 6LoWPAN Routing Header
draft-ietf-roll-routing-dispatch-02 draft-ietf-roll-routing-dispatch-03
Abstract Abstract
This specification introduces a new 6LoWPAN dispatch type for use in This specification introduces a new 6LoWPAN dispatch type for use in
6LoWPAN Route-Over topologies, that initially covers the needs of RPL 6LoWPAN Route-Over topologies, that initially covers the needs of RPL
(RFC6550) data packets compression. Using this dispatch type, this (RFC6550) data packets compression. Using this dispatch type, this
specification defines a method to compress RPL Option (RFC6553) specification defines a method to compress RPL Option (RFC6553)
information and Routing Header type 3 (RFC6554), an efficient IP-in- information and Routing Header type 3 (RFC6554), an efficient IP-in-
IP technique and is extensible for more applications. IP technique and is extensible for more applications.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 22, 2017. This Internet-Draft will expire on April 28, 2017.
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 1, line 89 skipping to change at page 1, line 89
5.4. Compression Reference for SRH-6LoRH header entries . . . 16 5.4. Compression Reference for SRH-6LoRH header entries . . . 16
5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 17 5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 17
5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17
6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 18 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 18
6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 19 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 19
6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 20 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 20
6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 20 6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 20
7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 23 7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 23
8. Management Considerations . . . . . . . . . . . . . . . . . . 24 8. Management Considerations . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 25 10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 26
10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 26 10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 26
10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 26 10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 28 A.1. Examples Compressing The RPI . . . . . . . . . . . . . . 29
A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 30 A.2. Example Of Downward Packet In Non-Storing Mode . . . . . 31
A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 32 A.3. Example of SRH-6LoRH life-cycle . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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, a very constrained resource in most cases.
The other constraints, such as the memory capacity and the duty The other constraints, such as the memory capacity and the duty
cycling of the LLN devices, derive from that primary concern. Energy cycling of the LLN devices, derive from that primary concern. Energy
is often available from primary batteries that are expected to last is often available from primary batteries that are expected to last
for years, or is scavenged from the environment in very limited for years, or is scavenged from the environment in very limited
quantities. Any protocol that is intended for use in LLNs must be quantities. Any protocol that is intended for use in LLNs must be
skipping to change at page 1, line 130 skipping to change at page 1, line 130
bytes per frame. The need to compress IPv6 packets over IEEE bytes per frame. The need to compress IPv6 packets over IEEE
802.15.4 led to the "6LoWPAN Header Compression" [RFC6282] work 802.15.4 led to the "6LoWPAN Header Compression" [RFC6282] work
(6LoWPAN_HC). (6LoWPAN_HC).
Innovative Route-over techniques have been and are still being Innovative Route-over techniques have been and are still being
developed for routing inside a LLN. In a general fashion, such developed for routing inside a LLN. In a general fashion, such
techniques require additional information in the packet to provide techniques require additional information in the packet to provide
loop prevention and to indicate information such as flow loop prevention and to indicate information such as flow
identification, source routing information, etc. identification, source routing information, etc.
For reasons such as security and the capability to send ICMP errors For reasons such as security and the capability to send ICMPv6 errors
back to the source, an original packet must not be tampered with, and (see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to
any information that must be inserted in or removed from an IPv6 the source, an original packet must not be tampered with, and any
packet must be placed in an extra IP-in-IP encapsulation. information that must be inserted in or removed from an IPv6 packet
must be placed in an extra IP-in-IP encapsulation .
This is the case when the additional routing information is inserted This is the case when the additional routing information is inserted
by a router on the path of a packet, for instance the root of a mesh, by a router on the path of a packet, for instance the root of a mesh,
as opposed to the source node, with the non-storing mode of the "IPv6 as opposed to the source node, with the non-storing mode of the "IPv6
Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL). Routing Protocol for Low-Power and Lossy Networks" [RFC6550] (RPL).
This is also the case when some routing information must be removed This is also the case when some routing information must be removed
from a packet that flows outside the LLN. from a packet that flows outside the LLN.
"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6" "When to use RFC 6553, RFC 6554 and IPv6-in-IPv6"
skipping to change at page 1, line 565 skipping to change at page 1, line 566
Figure 6: The SRH-6LoRH. Figure 6: The SRH-6LoRH.
The 6LoRH Type of a SRH-6LoRH header indicates the compression level The 6LoRH Type of a SRH-6LoRH header indicates the compression level
used for that header. used for that header.
The fields following the 6LoRH Type are compressed addresses The fields following the 6LoRH Type are compressed addresses
indicating the consecutive hops, and are ordered from the first to indicating the consecutive hops, and are ordered from the first to
the last hop. the last hop.
All the addresses in a given SRH-6LoRH header MUST be compressed in All the addresses in a given SRH-6LoRH header MUST be compressed in
an identical fashion, so the Length of the compressed for is the same an identical fashion, so the Length of the compressed form is the
for all. same for all.
In order to get different degrees of compression, multiple In order to get different degrees of compression, multiple
consecutive SRH-6LoRH headers MUST be used. consecutive SRH-6LoRH headers MUST be used.
Type 0 means that the address is compressed down to one byte, whereas Type 0 means that the address is compressed down to one byte, whereas
Type 4 means that the address is provided in full in the SRH-6LoRH Type 4 means that the address is provided in full in the SRH-6LoRH
with no compression. The complete list of Types of SRH-6LoRH and the with no compression. The complete list of Types of SRH-6LoRH and the
corresponding compression level are provided in Figure 7: corresponding compression level are provided in Figure 7:
+-----------+----------------------+ +-----------+----------------------+
skipping to change at page 1, line 1125 skipping to change at page 1, line 1126
fragment and for packets going upwards. fragment and for packets going upwards.
8. Management Considerations 8. Management Considerations
Though it is possible to decompress a packet at any hop, this Though it is possible to decompress a packet at any hop, this
specification is optimized to enable that a packet is forwarded in specification is optimized to enable that a packet is forwarded in
its compressed form all the way, and it makes sense to deploy its compressed form all the way, and it makes sense to deploy
homogeneous networks, where all nodes, or no node at all, use the homogeneous networks, where all nodes, or no node at all, use the
compression technique detailed therein. compression technique detailed therein.
This specification does not provide a method to discover the This specification aims at a simple implementation running in
capability by a next-hop device to support the compression technique, constrained nodes, so it does indeed expect an homogeneous network
or the incremental addition of 6LoWPAN Routing Header as new and as a consequence it does not provide a method to determine the
specifications are published, considering that such extraneous code level of support by the next hops at forwarding time.
would overburden many constrained devices. This specification does
not require extraneous code to exchange and handle error messages for
mismatch situations, either.
It is thus critical to keep the network homogeneous, or at least Should an extension to this specification provide such a method,
provide in forwarding nodes the knowledge of the support by the next forwarding nodes could compress or uncompress the RPL artifacts
hops. This is either a deployment issue, by deploying only devices appropriately and enable a backward compatibility between nodes that
with a same capability, or a management issue, by configuring all support this specification and nodes that do not.
devices to either use, or not use, a certain level of this
compression technique and its future additions. It results that this specification does not attempt to enable such
backwards compatibility. It does not require extraneous code to
exchange and handle error messages to correct automatically mismatch
situations, either.
When a packet is expected to carry a 6LoRH header but it does not,
the node that discovers the issue is expected to send an ICMPv6 error
message to the root, at an adapted rate limitation and with a Type 4
indicating a "Parameter Problem", and a Code 0 indicating an
"erroneous header field encountered", embedding the relevant portion
of the received packet and pointing at the offset therein where the
6LoRH header was expected.
When a packet is received with a 6LoRH header that is not recognized,
the node that discovers the issue is expected to send an ICMPv6 error
message, to the root, at an adapted rate limitation and with a Type 4
indicating a "Parameter Problem", and a Code 1 indicating an
"unrecognized Next Header type", embedding the relevant portion of
the received packet and pointing at the offset therein where the
6LoRH header was expected.
In both cases, the node SHOULD NOT place a 6LoRH header defined in
this specification in the resulting message, and should either omit
the RPI or place it uncompressed after the IPv6 header.
In both cases also, an alternate management method may be preferred
in order to notify the network administrator that there is a
configuration error.
Keeping the network homogeneous is either a deployment issue, by
deploying only devices with a same capability, or a management issue,
by configuring all devices to either use, or not use, a certain level
of this compression technique and its future additions.
In particular, the situation where a node receives a message with a In particular, the situation where a node receives a message with a
Critical 6LoWPAN Routing Header that it does not understand is an Critical 6LoWPAN Routing Header that it does not understand is an
administrative error whereby the wrong device is placed in a network, administrative error whereby the wrong device is placed in a network,
or the device is mis-configured. or the device is mis-configured.
When a mismatch situation is detected, it is expected that the device When a mismatch situation is detected, it is expected that the device
raises some management alert, indicating the issue, e.g. that it has raises some management alert, indicating the issue, e.g. that it has
to drop a packet with a Critical 6LoRH. to drop a packet with a Critical 6LoRH.
skipping to change at page 27, line 14 skipping to change at page 27, line 41
[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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[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>.
[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>.
skipping to change at page 28, line 15 skipping to change at page 28, line 49
12.2. Informative References 12.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), June 2016. in progress), June 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-08 (work in progress), September 2016. useofrplinfo-09 (work in progress), October 2016.
[I-D.thubert-6lo-forwarding-fragments] [I-D.thubert-6lo-forwarding-fragments]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-6lo-forwarding-fragments-02 (work Recovery", draft-thubert-6lo-forwarding-fragments-02 (work
in progress), November 2014. in progress), November 2014.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
skipping to change at page 31, line 8 skipping to change at page 32, line 8
If the last hop in a SRH-6LoRH is not the final destination then it If the last hop in a SRH-6LoRH is not the final destination then it
removes the SRH-6LoRH before forwarding. removes the SRH-6LoRH before forwarding.
In the particular example illustrated in Figure 20, all addresses in In the particular example illustrated in Figure 20, all addresses in
the DODAG are assigned from a same /112 prefix and the last 2 octets the DODAG are assigned from a same /112 prefix and the last 2 octets
encoding an identifier such as a IEEE 802.15.4 short address. In encoding an identifier such as a IEEE 802.15.4 short address. In
that case, all addresses can be compressed to 2 octets, using the that case, all addresses can be compressed to 2 octets, using the
root address as reference. There will be one SRH_6LoRH header, with, root address as reference. There will be one SRH_6LoRH header, with,
in this example, 3 compressed addresses: in this example, 3 compressed addresses:
+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001 |SRH-6LoRH | RPI-6LoRH | IP-in-IP | NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=2 | | 6LoRH |LOWPAN_IPHC | UDP | hdr |load |Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-8bytes-> <- RFC 6282 -> <-8bytes-> <- RFC 6282 ->
No RPL artifact No RPL artifact
Figure 20: Example Compressed Packet with SRH. Figure 20: Example Compressed Packet with SRH.
One may note that the RPI is provided. This is because the address One may note that the RPI is provided. This is because the address
of the root that is the source of the IP-in-IP header is elided and of the root that is the source of the IP-in-IP header is elided and
inferred from the RPLInstanceID in the RPI. Once found from a local inferred from the RPLInstanceID in the RPI. Once found from a local
context, that address is used as Compression Reference to expand context, that address is used as Compression Reference to expand
addresses in the SRH-6LoRH. addresses in the SRH-6LoRH.
With the RPL specifications available at the time of writing this With the RPL specifications available at the time of writing this
 End of changes. 14 change blocks. 
40 lines changed or deleted 76 lines changed or added

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