--- 1/draft-ietf-roll-routing-dispatch-04.txt 2016-10-27 06:16:28.290724979 -0700 +++ 2/draft-ietf-roll-routing-dispatch-05.txt 2016-10-27 06:16:28.366726894 -0700 @@ -1,23 +1,23 @@ roll P. Thubert, Ed. Internet-Draft Cisco Intended status: Standards Track C. Bormann -Expires: April 29, 2017 Uni Bremen TZI +Expires: April 30, 2017 Uni Bremen TZI L. Toutain IMT-TELECOM Bretagne R. Cragie ARM - October 26, 2016 + October 27, 2016 6LoWPAN Routing Header - draft-ietf-roll-routing-dispatch-04 + draft-ietf-roll-routing-dispatch-05 Abstract This specification introduces a new 6LoWPAN dispatch type for use in 6LoWPAN Route-Over topologies, that initially covers the needs of RPL (RFC6550) data packets compression. Using this dispatch type, this specification defines a method to compress RPL Option (RFC6553) information and Routing Header type 3 (RFC6554), an efficient IP-in- IP technique and is extensible for more applications. @@ -29,21 +29,21 @@ 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 29, 2017. + This Internet-Draft will expire on April 30, 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 @@ -106,26 +106,26 @@ The other constraints, such as the memory capacity and the duty cycling of the LLN devices, derive from that primary concern. Energy is often available from primary batteries that are expected to last for years, or is scavenged from the environment in very limited quantities. Any protocol that is intended for use in LLNs must be designed with the primary concern of saving energy as a strict requirement. Controlling the amount of data transmission is one possible venue to save 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). + to much smaller values than the guaranteed 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). Innovative Route-over techniques have been and are still being developed for routing inside a LLN. In a general fashion, such techniques require additional information in the packet to provide loop prevention and to indicate information such as flow identification, source routing information, etc. For reasons such as security and the capability to send ICMPv6 errors (see "Internet Control Message Protocol (ICMPv6)" [RFC4443]) back to the source, an original packet must not be tampered with, and any @@ -329,21 +329,21 @@ headers and encapsulates the result in IP-in-IP. With this specification, the chains of headers MUST be compressed in 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 encapsulations, the first IP-in-IP encapsulation, with all its chain of headers, is encoded first in the compressed form. 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 - (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 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 encapsulation, placing the 6LoRH headers next to one another may present an ambiguity on which header belong to which chain in the uncompressed form. In order to disambiguate the headers that follow the inner IPv6 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 @@ -461,25 +461,25 @@ 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 length than the address that is being coalesced. A compressed address is expanded by coalescing it with a reference 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 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 - RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference + RRRRRRRRRRRRCCCCCCC coalesced address, same compression as reference Figure 5: Coalescing addresses. 4.3.2. DODAG Root Address Determination Stateful Address compression requires that some state is installed in the devices to store the compression information that is elided from 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 information from the context table. @@ -501,29 +501,29 @@ RPLInstanceID that is present in the RPI is enough information to identify the DODAG that this node participates to and its associated root. But for a Local Instance, the address of the root MUST be explicit, either in some device configuration or signaled in the packet, as the source or the destination address, respectively. When implicit, the address of the DODAG root MUST be determined as follows: 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 - does not expose that property, it can only be known by a + known and does not need to be signaled in the packets. But since + RPL does not expose that property, it can only be known by a configuration applied to all nodes. - Else, the router that encapsulates the packet and compresses it with - this specification MUST also place an RPI in the packet as prescribed - by RPL to enable the identification of the DODAG. The RPI must be - present even in the case when the router also places an SRH header in - the packet. + Else, the router that encapsulates the packet and compresses it + with this specification MUST also place an RPI in the packet as + prescribed by RPL to enable the identification of the DODAG. The + RPI must be present even in the case when the router also places + an SRH header in the packet. It is expected that the RPL implementation maintains an abstract context table, indexed by Global RPLInstanceID, that provides the address of the root of the DODAG that this nodes participates to for that particular RPL Instance. 5. The SRH 6LoRH Header 5.1. Encoding @@ -971,21 +971,21 @@ Figure 9: The Generic RPI-6LoRH Format. O, R, and F bits: The O, R, and F bits are defined in section 11.2 of RFC 6550 [RFC6550]. I flag: If it is set, the RPLInstanceID is elided and the RPLInstanceID is the Global RPLInstanceID 0. If it is not set, the octet immediately following the type field contains the 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, with the least significant octet elided. If it is not set, the SenderRank, is fully inlined as two octets. In Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256 so the least significant byte is all zeros and can be elided: 0 1 2 @@ -1165,21 +1165,21 @@ 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 Critical 6LoWPAN Routing Header that it does not understand is an administrative error whereby the wrong device is placed in a network, or the device is mis-configured. 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. 9. Security Considerations The security considerations of RFC 4944 [RFC4944], RFC 6282 [RFC6282], and RFC 6553 [RFC6553] apply. 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 new threat when compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553] @@ -1424,21 +1424,21 @@ A.2. Example Of Downward Packet In Non-Storing Mode The example illustrated in Figure 20 is a classical packet in non- 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 reach a destination. In the non-compressed form, when the root 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 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]. When compressed with this specification, the 4 hops are encoded in SRH-6LoRH when the root generates the packet, and the final destination is left in the LOWPAN_IPHC. There is no swap, and the forwarding node that corresponds to the first entry effectively consumes it when forwarding, which means that the size of the encoded packet decreases and that the hop information is lost. If the last hop in a SRH-6LoRH is not the final destination then it @@ -1572,21 +1572,21 @@ Figure 25: Processing at Node D. Authors' Addresses Pascal Thubert (editor) Cisco Systems Building D - Regus 45 Allee des Ormes BP1200 MOUGINS - Sophia Antipolis 06254 - FRANCE + France Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany