draft-ietf-roll-routing-dispatch-04.txt   draft-ietf-roll-routing-dispatch-05.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 29, 2017 Uni Bremen TZI Expires: April 30, 2017 Uni Bremen TZI
L. Toutain L. Toutain
IMT-TELECOM Bretagne IMT-TELECOM Bretagne
R. Cragie R. Cragie
ARM ARM
October 26, 2016 October 27, 2016
6LoWPAN Routing Header 6LoWPAN Routing Header
draft-ietf-roll-routing-dispatch-04 draft-ietf-roll-routing-dispatch-05
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 29, 2017. This Internet-Draft will expire on April 30, 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 117 skipping to change at page 1, line 117
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
designed with the primary concern of saving energy as a strict designed with the primary concern of saving energy as a strict
requirement. requirement.
Controlling the amount of data transmission is one possible venue to Controlling the amount of data transmission is one possible venue to
save energy. In a number of LLN standards, the frame size is limited save energy. In a number of LLN standards, the frame size is limited
to much smaller values than the IPv6 maximum transmission unit (MTU) to much smaller values than the guaranteed 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).
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 ICMPv6 errors For reasons such as security and the capability to send ICMPv6 errors
(see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to (see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to
the source, an original packet must not be tampered with, and any the source, an original packet must not be tampered with, and any
skipping to change at page 1, line 340 skipping to change at page 1, line 340
headers and encapsulates the result in IP-in-IP. headers and encapsulates the result in IP-in-IP.
With this specification, the chains of headers MUST be compressed in With this specification, the chains of headers MUST be compressed in
the same order as they appear in the uncompressed form of the packet. the same order as they appear in the uncompressed form of the packet.
This means that if there is more than one nested IP-in-IP This means that if there is more than one nested IP-in-IP
encapsulations, the first IP-in-IP encapsulation, with all its chain encapsulations, the first IP-in-IP encapsulation, with all its chain
of headers, is encoded first in the compressed form. of headers, is encoded first in the compressed form.
In the compressed form of a packet that has a Source Route or a Hop- In the compressed form of a packet that has a Source Route or a Hop-
by-Hop (HbH) Options Header [RFC2460] after the inner IPv6 header by-Hop (HbH) Options Header [RFC2460] after the inner IPv6 header
(e.g. if there is no IP-in-IP encapsulation), these headers are (e.g., if there is no IP-in-IP encapsulation), these headers are
placed in the 6LoRH form before the 6LOWPAN_IPHC that represents the placed in the 6LoRH form before the 6LOWPAN_IPHC that represents the
IPv6 header (see Section 3.2.1). If this packet gets encapsulated IPv6 header (see Section 3.2.1). If this packet gets encapsulated
and some other SRH or HbH Options Headers are added as part of the and some other SRH or HbH Options Headers are added as part of the
encapsulation, placing the 6LoRH headers next to one another may encapsulation, placing the 6LoRH headers next to one another may
present an ambiguity on which header belong to which chain in the present an ambiguity on which header belong to which chain in the
uncompressed form. uncompressed form.
In order to disambiguate the headers that follow the inner IPv6 In order to disambiguate the headers that follow the inner IPv6
header in the uncompressed form from the headers that follow the header in the uncompressed form from the headers that follow the
outer IP-in-IP header, it is REQUIRED that the compressed IP-in-IP outer IP-in-IP header, it is REQUIRED that the compressed IP-in-IP
skipping to change at page 1, line 472 skipping to change at page 1, line 472
The reference address MAY be a compressed address as well, in which The reference address MAY be a compressed address as well, in which
case it MUST be compressed in a form that is of an equal or greater case it MUST be compressed in a form that is of an equal or greater
length than the address that is being coalesced. length than the address that is being coalesced.
A compressed address is expanded by coalescing it with a reference A compressed address is expanded by coalescing it with a reference
address. In the particular case of a Type 4 SRH-6LoRH, the address address. In the particular case of a Type 4 SRH-6LoRH, the address
is expressed in full and the coalescence is a complete override as is expressed in full and the coalescence is a complete override as
illustrated in Figure 5. illustrated in Figure 5.
RRRRRRRRRRRRRRRRRRRR reference address, may be compressed or not RRRRRRRRRRRRRRRRRRR reference address, may be compressed or not
CCCCCCC compressed address, shorter or same as reference CCCCCCC compressed address, shorter or same as reference
RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference RRRRRRRRRRRRCCCCCCC coalesced address, same compression as reference
Figure 5: Coalescing addresses. Figure 5: Coalescing addresses.
4.3.2. DODAG Root Address Determination 4.3.2. DODAG Root Address Determination
Stateful Address compression requires that some state is installed in Stateful Address compression requires that some state is installed in
the devices to store the compression information that is elided from the devices to store the compression information that is elided from
the packet. That state is stored in an abstract context table and the packet. That state is stored in an abstract context table and
some form of index is found in the packet to obtain the compression some form of index is found in the packet to obtain the compression
information from the context table. information from the context table.
skipping to change at page 1, line 511 skipping to change at page 1, line 511
DODAGID field of the DIO messages. For a Global Instance, the DODAGID field of the DIO messages. For a Global Instance, the
RPLInstanceID that is present in the RPI is enough information to RPLInstanceID that is present in the RPI is enough information to
identify the DODAG that this node participates to and its associated identify the DODAG that this node participates to and its associated
root. But for a Local Instance, the address of the root MUST be root. But for a Local Instance, the address of the root MUST be
explicit, either in some device configuration or signaled in the explicit, either in some device configuration or signaled in the
packet, as the source or the destination address, respectively. packet, as the source or the destination address, respectively.
When implicit, the address of the DODAG root MUST be determined as When implicit, the address of the DODAG root MUST be determined as
follows: follows:
If the whole network is a single DODAG then the root can be well- If the whole network is a single DODAG then the root can be well-
known and does not need to be signaled in the packets. But since RPL known and does not need to be signaled in the packets. But since
does not expose that property, it can only be known by a RPL does not expose that property, it can only be known by a
configuration applied to all nodes. configuration applied to all nodes.
Else, the router that encapsulates the packet and compresses it with Else, the router that encapsulates the packet and compresses it
this specification MUST also place an RPI in the packet as prescribed with this specification MUST also place an RPI in the packet as
by RPL to enable the identification of the DODAG. The RPI must be prescribed by RPL to enable the identification of the DODAG. The
present even in the case when the router also places an SRH header in RPI must be present even in the case when the router also places
the packet. an SRH header in the packet.
It is expected that the RPL implementation maintains an abstract It is expected that the RPL implementation maintains an abstract
context table, indexed by Global RPLInstanceID, that provides the context table, indexed by Global RPLInstanceID, that provides the
address of the root of the DODAG that this nodes participates to for address of the root of the DODAG that this nodes participates to for
that particular RPL Instance. that particular RPL Instance.
5. The SRH 6LoRH Header 5. The SRH 6LoRH Header
5.1. Encoding 5.1. Encoding
skipping to change at page 1, line 982 skipping to change at page 1, line 982
Figure 9: The Generic RPI-6LoRH Format. Figure 9: The Generic RPI-6LoRH Format.
O, R, and F bits: The O, R, and F bits are defined in section 11.2 O, R, and F bits: The O, R, and F bits are defined in section 11.2
of RFC 6550 [RFC6550]. of RFC 6550 [RFC6550].
I flag: If it is set, the RPLInstanceID is elided and the I flag: If it is set, the RPLInstanceID is elided and the
RPLInstanceID is the Global RPLInstanceID 0. If it is not set, RPLInstanceID is the Global RPLInstanceID 0. If it is not set,
the octet immediately following the type field contains the the octet immediately following the type field contains the
RPLInstanceID as specified in section 5.1 of RFC 6550 RPLInstanceID as specified in section 5.1 of RFC 6550
[RFC6550],. [RFC6550].
K flag: If it is set, the SenderRank is compressed into one octet, K flag: If it is set, the SenderRank is compressed into one octet,
with the least significant octet elided. If it is not set, the with the least significant octet elided. If it is not set, the
SenderRank, is fully inlined as two octets. SenderRank, is fully inlined as two octets.
In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and
the MinHopRankIncrease is a multiple of 256 so the least significant the MinHopRankIncrease is a multiple of 256 so the least significant
byte is all zeros and can be elided: byte is all zeros and can be elided:
0 1 2 0 1 2
skipping to change at page 1, line 1176 skipping to change at page 1, line 1176
deploying only devices with a same capability, or a management issue, deploying only devices with a same capability, or a management issue,
by configuring all devices to either use, or not use, a certain level by configuring all devices to either use, or not use, a certain level
of this compression technique and its future additions. 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.
9. Security Considerations 9. Security Considerations
The security considerations of RFC 4944 [RFC4944], RFC 6282 The security considerations of RFC 4944 [RFC4944], RFC 6282
[RFC6282], and RFC 6553 [RFC6553] apply. [RFC6282], and RFC 6553 [RFC6553] apply.
Using a compressed format as opposed to the full in-line format is Using a compressed format as opposed to the full in-line format is
logically equivalent and is believed to not create an opening for a logically equivalent and is believed to not create an opening for a
new threat when compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553] new threat when compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553]
skipping to change at page 31, line 36 skipping to change at page 31, line 36
A.2. Example Of Downward Packet In Non-Storing Mode A.2. Example Of Downward Packet In Non-Storing Mode
The example illustrated in Figure 20 is a classical packet in non- The example illustrated in Figure 20 is a classical packet in non-
Storing mode for a packet going down the DODAG following a source Storing mode for a packet going down the DODAG following a source
routed path from the root. Say that we have 4 forwarding hops to routed path from the root. Say that we have 4 forwarding hops to
reach a destination. In the non-compressed form, when the root reach a destination. In the non-compressed form, when the root
generates the packet, the last 3 hops are encoded in a Routing Header generates the packet, the last 3 hops are encoded in a Routing Header
type 3 (SRH) and the first hop is the destination of the packet. The type 3 (SRH) and the first hop is the destination of the packet. The
intermediate hops perform a swap and the hop count indicates the intermediate hops perform a swap and the hop count indicates the
current active hop as defiend in RFC 2460 [RFC2460] and RFC 6554 current active hop as defined in RFC 2460 [RFC2460] and RFC 6554
[RFC6554]. [RFC6554].
When compressed with this specification, the 4 hops are encoded in When compressed with this specification, the 4 hops are encoded in
SRH-6LoRH when the root generates the packet, and the final SRH-6LoRH when the root generates the packet, and the final
destination is left in the LOWPAN_IPHC. There is no swap, and the destination is left in the LOWPAN_IPHC. There is no swap, and the
forwarding node that corresponds to the first entry effectively forwarding node that corresponds to the first entry effectively
consumes it when forwarding, which means that the size of the encoded consumes it when forwarding, which means that the size of the encoded
packet decreases and that the hop information is lost. packet decreases and that the hop information is lost.
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
skipping to change at page 35, line 22 skipping to change at page 35, line 22
Figure 25: Processing at Node D. Figure 25: Processing at Node D.
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
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
 End of changes. 15 change blocks. 
27 lines changed or deleted 27 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/