idnits 2.17.1 draft-thubert-6lo-routing-dispatch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to directly say this. It does mention RFC4944 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2015) is 3385 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 781, but not defined == Unused Reference: 'I-D.bormann-6lo-rpl-mesh' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lo-rpl-nhc' is defined on line 874, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-02) exists of draft-bergmann-bier-ccast-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-04 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-05 == Outdated reference: A later version (-08) exists of draft-thubert-6lo-forwarding-fragments-02 == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-02 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 4944 (if approved) C. Bormann 5 Intended status: Standards Track Uni Bremen TZI 6 Expires: July 23, 2015 L. Toutain 7 IMT-TELECOM Bretagne 8 R. Cragie 9 AMR 10 January 19, 2015 12 A Routing Header Dispatch for 6LoWPAN 13 draft-thubert-6lo-routing-dispatch-02 15 Abstract 17 This specification provides a new 6LoWPAN dispatch type for use in 18 Route-over and mixed Mesh-under and Route-over topologies, that 19 reuses the encoding of the mesh type defined in RFC 4944 for pure 20 Mesh-under topologies. This specification also defines a method to 21 compress RPL Option (RFC6553) information and Routing Header type 3 22 (RFC6554), an efficient IP-in-IP technique and opens the way for 23 further routing techniques. This extends 6LoWPAN Transmission of 24 IPv6 Packets (RFC4944), and is applicable to new link-layer types 25 where 6LoWPAN is being defined. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 23, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 5 64 4. General Format . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Critical Format {LoRHC} . . . . . . . . . . . . . . . . . 6 67 4.3. Placement of 6LoRH . . . . . . . . . . . . . . . . . . . 7 68 4.3.1. 6LoRH before Fragmentation Type and Header . . . . . 7 69 4.3.2. 6LoRH after Fragmentation Type and Header . . . . . . 7 70 5. The Routing Header type 3 (RH3) 6LoRH . . . . . . . . . . . . 7 71 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 9 72 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 10 73 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 10 74 6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 11 75 7. The IP-in-IP 6LoRH . . . . . . . . . . . . . . . . . . . . . 13 76 8. The Mesh Header 6LoRH . . . . . . . . . . . . . . . . . . . . 14 77 9. The BIER 6LoRH . . . . . . . . . . . . . . . . . . . . . . . 15 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 83 13.2. Informative References . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 The design of Low Power and Lossy Networks (LLNs) is generally 89 focused on saving energy, which is the most constrained resource of 90 all. The other constraints, such as the memory capacity and the duty 91 cycling of the LLN devices, derive from that primary concern. Energy 92 is often available from primary batteries that are expected to last 93 for years, or is scavenged from the environment in very limited 94 quantities. Any protocol that is intended for use in LLNs must be 95 designed with the primary concern of saving energy as a strict 96 requirement. 98 Controlling the amount of data transmission is one possible venue to 99 save energy. In a number of LLN standards, the frame size is limited 100 to much smaller values than the IPv6 maximum transmission unit (MTU) 101 of 1280 bytes. In particular, an LLN that relies on the classical 102 Physical Layer (PHY) of IEEE 802.14.5 [IEEE802154] is limited to 127 103 bytes per frame. The need to compress IPv6 packets over IEEE 104 802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work 105 (6LoWPAN-HC). 107 Innovative Route-over techniques have been and are still being 108 developed for routing inside a LLN. In a general fashion, such 109 techniques require additional information in the packet to provide 110 loop prevention and to indicate information such as flow 111 identification, source routing information, etc. 113 For reasons such as security and the capability to send ICMP errors 114 back to the source, an original packet must not be tampered with, and 115 any information that must be inserted in or removed from an IPv6 116 packet must be placed in an extra IP-in-IP encapsulation. This is 117 the case when the additional routing information is inserted by a 118 router on the path of a packet, for instance a mesh root, as opposed 119 to the source node. This is also the case when some routing 120 information must be removed from a packet that will flow outside the 121 LLN. 123 As an example, the Routing Protocol for Low Power and Lossy Networks 124 [RFC6550] (RPL) is designed to optimize the routing operations in 125 constrained LLNs. As part of this optimization, RPL requires the 126 addition of RPL Packet Information (RPI) in every packet, as defined 127 in Section 11.2 of [RFC6550]. 129 The RPL Option for Carrying RPL Information in Data-Plane Datagrams 130 [RFC6553] specification indicates how the RPI can be placed in a RPL 131 Option for use in an IPv6 Hop-by-Hop header. This representation 132 demands a total of 8 bytes when in most cases the actual RPI payload 133 requires only 19 bits. Since the Hop-by-Hop header must not flow 134 outside of the RPL domain, it must be removed from packets that leave 135 the domain, and be inserted in packets entering the domain. In both 136 cases, this operation implies an IP-in-IP encapsulation. 138 ------+--------- ^ 139 | Internet | 140 | | Native IPv6 141 +-----+ | 142 | | Border Router (RPL Root) ^ | ^ 143 | | | | | 144 +-----+ | | | IPv6 in 145 | | | | IPv6 146 o o o o | | | + RPI 147 o o o o o o o o o | | | or RH3 148 o o o o o o o o o o | | | 149 o o o o o o o o o | | | 150 o o o o o o o o v v v 151 o o o o 152 LLN 154 Figure 1: IP-in-IP Encapsulation within the LLN 156 Additionally, in the case of the Non-Storing Mode of Operation (MOP), 157 RPL requires a Routing Header type 3 (RH3) as defined in the IPv6 158 Routing Header for Source Routes with RPL [RFC6554] specification, 159 for all packets that are routed down a RPL graph. With Non-Storing 160 RPL, even if the source is a node in the same LLN, the packet must 161 first reach up the graph to the root so that the root can insert the 162 RH3 to go down the graph. In any fashion, whether the packet was 163 originated in a node in the LLN or outside the LLN, and regardless of 164 whether the packet stays within the LLN or not, as long as the source 165 of the packet is not the root itself, the source-routing operation 166 also implies an IP-in-IP encapsulation at the root to insert the RH3. 168 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 169 over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) 170 mode of operation of IEEE 802.14.5. The architecture requires the 171 use of both RPL and the 6lo adaptation layer framework ([RFC4944], 172 [RFC6282]) over IEEE 802.14.5. Because it inherits the constraints 173 on the frame size from the MAC layer, 6TiSCH cannot afford to spend 8 174 bytes per packet on the RPI. Hence the requirement for a 6LoWPAN 175 header compression of the RPI. 177 The type of information that needs to be present in a packet inside 178 the LLN but not outside of the LLN varies with the routing operation, 179 but there is overall a need for an extensible compression technique 180 that would simplify the IP-in-IP encapsulation, when needed, and 181 optimally compress existing routing artifacts found in LLNs. 183 This specification extends 6LoWPAN [RFC4944] and in particular reuses 184 the Mesh Header formats that are defined for the Mesh-under use cases 185 so as to carry routing information for Route-over use cases. The 186 specification includes the formats necessary for RPL and is 187 extensible for additional formats. 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in 194 [RFC2119]. 196 The Terminology used in this document is consistent with and 197 incorporates that described in `Terminology in Low power And Lossy 198 Networks' [RFC7102] and [RFC6550]. 200 The terms Route-over and Mesh-under are defined in [RFC6775]. 202 Other terms in use in LLNs are found in [RFC7228]. 204 The term "byte" is used in its now customary sense as a synonym for 205 "octet". 207 3. Updating RFC 4944 209 Section 5.1 of the IPv6 over IEEE 802.15.4 [RFC4944] specification 210 defines various Dispatch Types and Headers, and in particular a Mesh 211 Header that corresponds to a pattern 10xxxxxx and effectively 212 consumes one third of the whole 6LoWPAN dispatch space for Mesh-under 213 specific applications. 215 This specification reuses the Dispatch space for Route-over and mixed 216 operations. This means that a device that use the Mesh Header as 217 specified in [RFC4944] should not be placed in a same network as a 218 device which operates per this update. This is generally not a 219 problem since a network is classically either Mesh-under OR Route- 220 over. 222 A new implementation of Mesh-under MAY support both types of 223 encoding, and if so, it SHOULD provide a management toggle to enable 224 either mode and it SHOULD use this specification as the default mode. 226 4. General Format 228 The 6LoWPAN Routing Header (6LoRH) reuses the bit patterns that are 229 defined in [RFC4944] for the Mesh Header, specifically the Dispatch 230 Value Bit Pattern of 10xxxxxx. 231 It may contain source routing information such as a compressed form 232 of RH3, or other sorts of routing information such as the RPL RPI, 233 source and/or destination address, and is extensible for future uses, 234 with the given example of BIER bitmap encoding in Section 9. 236 There are two forms for 6LoRH: > Elective (6LoRHE) > Critical 237 (6LoRHC) 239 4.1. Elective Format 241 The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. 242 A 6LoRHE may be ignored and skipped in parsing. 243 If it is ignored, the 6LoRHE is forwarded with no change inside the 244 LLN. 246 0 1 247 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 249 |1|0|1| Length | Type | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 251 <-- Length --> 253 Figure 2: Elective 6LoWPAN Routing Header 255 Length: 256 Length of the 6LoRHE expressed in bytes, excluding the first 2 257 bytes. This is done to enable a node to skip a 6LoRH that it does 258 not support and/or cannot parse, for instance if the Type is not 259 known. 261 Type: 262 Type of the 6LoRHE 264 4.2. Critical Format {LoRHC} 266 The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx. 267 A node which does not support the 6LoRHC Type MUST silently discard 268 the packet (note that there is no provision for the exchange of error 269 messages; such a situation should be avoided by judicious use of 270 administrative control and/or capability indications). 272 0 1 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 275 |1|0|0| TSE | Type | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 277 <-- Length implied by Type/TSE --> 279 Figure 3: Critical 6LoWPAN Routing Header 281 TSE: 282 Type Specific Extension. The meaning depends on the Type, which 283 must be known in all of the nodes. The interpretation of the TSE 284 depends on the Type field that follows. For instance, it may be 285 used to transport control bits, the number of elements in an 286 array, or the length of the remainder of the 6LoRHC expressed in a 287 unit other than bytes. 289 Type: 290 Type of the 6LoRHC 292 4.3. Placement of 6LoRH 294 One or more 6LoRHs MAY be placed in a 6LoWPAN packet and MUST always 295 be placed before the LOWPAN_IPHC [RFC6282]. A 6LoRH MAY be used in 296 conjunction with a Fragmentation Type and Header [RFC4944] in three 297 ways: > Before the Fragmentation Type and Header > Before and after 298 the Fragmentation Type and Header > After the Fragmentation Type and 299 Header 301 Headers are processed in order so if a 6LoRH is processed that is 302 sufficient to route a packet, then there is no need for the 303 intermediate node to process the packet further. 305 4.3.1. 6LoRH before Fragmentation Type and Header 307 | 6LoRH | Frag1 | IPHC | Payload Frag1 | 308 | 6LoRH | FragN | Payload Frag2 | 309 | 6LoRH | FragN | Payload Frag3 |... 311 If a 6LoRH is placed before a Fragmentation Type and Header, the 312 fragments can be routed individually. 314 4.3.2. 6LoRH after Fragmentation Type and Header 316 | Frag1 | 6LoRH | IPHC | Payload Frag1 | 317 | FragN | Payload Frag2 | 318 | FragN | Payload Frag3 |... 320 If a 6LoRH is placed after a Fragmentation Type and Header, the 321 fragments cannot be individually routed and the whole IPv6 packet 322 needs to be reassembled at every LLN hop. 324 5. The Routing Header type 3 (RH3) 6LoRH 326 The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) is a Critical 327 6LoWPAN Routing Header that provides a compressed form for the RH3, 328 as defined in [RFC6554] for use by RPL routers. Routers that need to 329 forward a packet with a RH3-6LoRH are expected to be RPL routers and 330 expected to support this specification. If a non-RPL router receives 331 a packet with a RPI-6LoRH, this means that there was a routing error 332 and the packet should be dropped so the Type cannot be ignored. 334 0 1 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 337 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 340 Size indicates the number of compressed addresses 342 Figure 4: The RH3-6LoRH 344 The values for the RH3-6LoRH Type are an enumeration, 0 to 4. The 345 form of compression is indicated by the Type as follows: 347 +-----------+-----------+ 348 | Type | Size Unit | 349 +-----------+-----------+ 350 | 0 | 1 | 351 | 1 | 2 | 352 | 2 | 4 | 353 | 3 | 8 | 354 | 4 | 16 | 355 +-----------+-----------+ 357 Figure 5: The RH3-6LoRH Types 359 In the case of a RH3-6LoRH, the TSE field is used as a Size, which 360 encodes the number of hops minus 1; so a Size of 0 means one hop, and 361 the maximum that can be encoded is 32 hops. (If more than 32 hops 362 need to be expressed, a sequence of RH3-6LoRH can be employed.) 364 The next Hop is indicated in the first entry of the first RH3-6LoRH. 365 Upon reception, the entry is checked whether it refers to the 366 processing router itself. If it so, the entry is removed from the 367 RH3-6LoRH and the Size is decremented. If the Size is now zero, the 368 whole RH3-6LoRH is removed. If there is no more RH3-6LoRH, the 369 processing node is the last router on the way, which may or may not 370 be collocated with the final destination. 372 The last hop in the last RH3-6LoRH is the last router prior to the 373 destination in the LLN. So even when there is a RH3-6LoRH in the 374 frame, the address of the final destination is in the LoWPAN_IPHC 375 [RFC6282]. 377 If some bits of the first address in the RH3-6LoRH can be derived 378 from the final destination is in the LoWPAN_IPHC, then that address 379 may be compressed, otherwise is is expressed in full. Next addresses 380 only need to express the delta from the previous address. 382 All addresses in a RH3-6LoRH are compressed in a same fashion, down 383 to the same number of bytes per address. In order to get different 384 forms of compression, multiple consecutive RH3-6LoRH must be used. 386 6. The RPL Packet Information 6LoRH 388 [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) 389 as a set of fields that are to be added to the IP packets for the 390 purpose of Instance Identification, as well as Loop Avoidance and 391 Detection. 393 In particular, the SenderRank, which is the scalar metric computed by 394 an specialized Objective Function such as [RFC6552], indicates the 395 Rank of the sender and is modified at each hop. The SenderRank 396 allows to validate that the packet progresses in the expected 397 direction, either upwards or downwards, along the DODAG. 399 RPL defines the RPL Option for Carrying RPL Information in Data-Plane 400 Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 401 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes 402 per packet. 404 With [RFC6553], the RPL option is encoded as six Octets; it must be 405 placed in a Hop-by-Hop header that consumes two additional octets for 406 a total of eight. In order to limit its range to the inside the RPL 407 domain, the Hop-by-Hop header must be added to (or removed from) 408 packets that cross the border of the RPL domain. 410 The 8-bytes overhead is detrimental to the LLN operation, in 411 particular with regards to bandwidth and battery constraints. These 412 bytes may cause a containing frame to grow above maximum frame size, 413 leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn 414 cause even more energy spending and issues discussed in the LLN 415 Fragment Forwarding and Recovery 416 [I-D.thubert-6lo-forwarding-fragments]. 418 An additional overhead comes from the need, in certain cases, to add 419 an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is 420 needed when the router that inserts the Hop-by-Hop header is not the 421 source of the packet, so that an error can be returned to the router. 422 This is also the case when a packet originated by a RPL node must be 423 stripped from the Hop-by-Hop header to be routed outside the RPL 424 domain. 426 This specification defines an IPinIP-6LoRH in Section 7 for that 427 purpose, but it must be noted that stripping a 6LoRH does not require 428 a manipulation of the packet in the LOWPAN_IPHC, and thus, if the 429 source address in the LOWPAN_IPHC is the node that inserted the 430 IPinIP-6LoRH then this alone does not mandate an IPinIP-6LoRH. 432 As a result, a RPL packet may bear only a RPI-6LoRH and no IPinIP- 433 6LoRH. In that case, the source and destination of the packet are 434 located in the LOWPAN_IPHC. 436 As with [RFC6553], the fields in the RPI include an 'O', an 'R', and 437 an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), 438 and a 16-bit SenderRank. 440 The remainder of this section defines the RPI-6LoRH, a Critical 441 6LoWPAN Routing Header that is designed to transport the RPI in 442 6LoWPAN LLNs. 444 6.1. Compressing the RPLInstanceID 446 RPL Instances are discussed in [RFC6550], Section 5. A number of 447 simple use cases will not require more than one instance, and in such 448 a case, the instance is expected to be the global Instance 0. A 449 global RPLInstanceID is encoded in a RPLInstanceID field as follows: 451 0 1 2 3 4 5 6 7 452 +-+-+-+-+-+-+-+-+ 453 |0| ID | Global RPLInstanceID in 0..127 454 +-+-+-+-+-+-+-+-+ 456 Figure 6: RPLInstanceID Field Format for Global Instances 458 For the particular case of the global Instance 0, the RPLInstanceID 459 field is all zeros. This specification allows to elide a 460 RPLInstanceID field that is all zeros, and defines a I flag that, 461 when set, signals that the field is elided. 463 6.2. Compressing the SenderRank 465 The SenderRank is the result of the DAGRank operation on the rank of 466 the sender; here the DAGRank operation is defined in [RFC6550], 467 Section 3.5.1, as: 469 DAGRank(rank) = floor(rank/MinHopRankIncrease) 471 If MinHopRankIncrease is set to a multiple of 256, the least 472 significant 8 bits of the SenderRank will be all zeroes; by eliding 473 those, the SenderRank can be compressed into a single byte. This 474 idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE 475 as 256 and in [RFC6552] that defaults MinHopRankIncrease to 476 DEFAULT_MIN_HOP_RANK_INCREASE. 478 This specification allows to encode the SenderRank as either one or 479 two bytes, and defines a K flag that, when set, signals that a single 480 byte is used. 482 6.3. The Overall RPI-6LoRH encoding 484 The RPI-6LoRH provides a compressed form for the RPL RPI. Routers 485 that need to forward a packet with a RPI-6LoRH are expected to be RPL 486 routers and expected to support this specification. If a non-RPL 487 router receives a packet with a RPI-6LoRH, this means that there was 488 a routing error and the packet should be dropped so the Type cannot 489 be ignored. 491 Since the I flag is not set, the TSE field does not need to be a 492 length expressed in bytes. The field is fully reused for control 493 bits so as to encode the O, R and F flags from the RPI, and the I and 494 K flags that indicate the compression that is taking place. 496 The Type for the RPI-6LoRH is 5. 498 The RPI-6LoRH is immediately followed by the RPLInstanceID field, 499 unless that field is fully elided, and then the SenderRank, which is 500 either compressed into one byte or fully in-lined as the whole 2 501 bytes. The I and K flags in the RPI-6LoRH indicate whether the 502 RPLInstanceID is elided and/or the SenderRank is compressed and 503 depending on these bits, the Length of the RPI-6LoRH may vary as 504 described hereafter. 506 0 1 2 507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 509 |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 512 Figure 7: The Generic RPI-6LoRH Format 514 O, R, and F bits: 515 The O, R, and F bits as defined in [RFC6550], Section 11.2. 517 I bit: 518 If it is set, the Instance ID is elided and the RPLInstanceID 519 is the Global RPLInstanceID 0. If it is not set, the octet 520 immediately following the type field contains the RPLInstanceID 521 as specified in [RFC6550] section 5.1. 523 K bit: 524 If it is set, the SenderRank is be compressed into one octet, 525 and the lowest significant octet is elided. If it is not set, 526 the SenderRank, is fully inlined as 2 octets. 528 In Figure 8, the RPLInstanceID is the Global RPLInstanceID 0, and the 529 MinHopRankIncrease is a multiple of 256 so the least significant byte 530 is all zeros and can be elided: 532 0 1 2 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 I=1, K=1 539 Figure 8: The most compressed RPI-6LoRH 541 In Figure 9, the RPLInstanceID is the Global RPLInstanceID 0, but 542 both bytes of the SenderRank are significant so it can not be 543 compressed: 545 0 1 2 3 546 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 I=1, K=0 552 Figure 9: Eliding the RPLInstanceID 554 In Figure 10, the RPLInstanceID is not the Global RPLInstanceID 0, 555 and the MinHopRankIncrease is a multiple of 256: 557 0 1 2 3 558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 I=0, K=1 564 Figure 10: Compressing SenderRank 566 In Figure 11, the RPLInstanceID is not the Global RPLInstanceID 0, 567 and both bytes of the SenderRank are significant: 569 0 1 2 3 570 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 |1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 ...-Rank | 575 +-+-+-+-+-+-+-+-+ 576 I=0, K=0 578 Figure 11: Least compressed form of RPI-6LoRH 580 A typical packet in RPL non-storing mode going down the RPL graph 581 requires an IPinIP encapsulating the RH3, whereas the RPI is usually 582 omitted, unless it is important to indicate the RPLInstanceID. To 583 match this structure, an optimized IPinIP 6LoRH is defined in 584 Section 7. 586 7. The IP-in-IP 6LoRH 588 The IP-in-IP 6LoRH (IPinIP-6LoRH) is an Elective 6LoWPAN Routing 589 Header that provides a compressed form for the encapsulating IPv6 590 Header in the case of an IP-in-IP encapsulation. 592 An IPinIP encapsulation is used to insert a field such as a Routing 593 Header or an RPI at a router that is not the source of the packet. 594 In order to send an error back regarding the inserted field, the 595 address of the router that performs the insertion must be provided. 597 The encapsulation can also enable a router down the path removing a 598 field such as the RPI, but this can be done in the compressed form by 599 removing the RPI-6LoRH, so an IPinIP-6LoRH encapsulation is not 600 required for that sole purpose. 602 This field is not critical for routing so the Type can be ignored, 603 and the TSE field contains the Length in bytes. 605 0 1 2 606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 608 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 611 Figure 12: The IPinIP-6LoRH 613 The Length of an IPinIP-6LoRH is expressed in bytes and MUST be at 614 least 1, to indicate a Hop Limit (HL), that is decremented at each 615 hop. When the HL reaches 0, the packet is dropped per [RFC2460] 616 If the Length of an IPinIP-6LoRH is exactly 1, then the Encapsulator 617 Address is elided, which means that the Encapsulator is a well-known 618 router, for instance the root in a RPL graph. 620 If the Length of an IPinIP-6LoRH is strictly more than 1, then an 621 Encapsulator Address is placed in a compressed form after the Hop 622 Limit field. The value of the Length indicates which compression is 623 performed on the Encapsulator Address. For instance, a Size of 3 624 indicates that the Encapsulator Address is compressed to 2 bytes. 626 When it cannot be elided, the destination IP address of the IP-in-IP 627 header is transported in a RH3-6LoRH as the first address of the 628 list. 630 With RPL, the destination address in the IP-in-IP header is 631 implicitly the root in the RPL graph for packets going upwards, and 632 the destination address in the IPHC for packets going downwards. If 633 the implicit value is correct, the destination IP address of the IP- 634 in-IP encapsulation can be elided. 636 If the final destination of the packet is a leaf that does not 637 support this specification, then the chain of 6LoRH must be stripped 638 by the RPL/6LR router to which the leaf is attached. In that 639 example, the destination IP address of the IP-in-IP header cannot be 640 elided. 642 In the special case where the 6LoRH is used to route 6LoWPAN 643 fragments, the destination address is not accessible in the IPHC on 644 all fragments and can be elided only for the first fragment and for 645 packets going upwards. 647 8. The Mesh Header 6LoRH 649 The Mesh Header 6LoRH (MH-6LoRH) is an Elective 6LoWPAN Routing 650 Header that provides an alternate form for the Mesh Addressing Type 651 and Header defined in [RFC4944] with the same semantics. 653 The MH-6LoRH is introduced as replacement for use in potentially 654 mixed Route_Over and Mesh-under environments. LLN nodes that need to 655 forward a packet with a MH-6LoRH are expected to support this 656 specification. If a router that supports only Route-over receives a 657 packet with a MH-6LoRH, this means that there was a routing error and 658 the packet should be dropped, so the Type cannot be ignored. 660 The HopsLft field defined in [RFC4944] is encoded in the TSE, so this 661 specification doubles the potential number of hops vs. [RFC4944]. 663 The HopsLft value of 0x1F is reserved and signifies an 8-bit Deep 664 Hops Left field immediately following the Type, and allows a source 665 node to specify a hop limit greater than 30 hops. 667 0 1 668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 670 |1|0|0| HopsLft |6LoRHType 8..11| originator address, final address | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 673 Figure 13: The MH-6LoRH 675 The V and F flags defined in [RFC4944] are encoded in the MH-6LoRH 676 Type as follows: 678 +-----------+-------+-------+ 679 | Type | V | F | 680 +-----------+-------+-------+ 681 | 8 | 0 | 0 | 682 | 9 | 0 | 1 | 683 | 10 | 1 | 0 | 684 | 11 | 1 | 1 | 685 +-----------+-------+-------+ 687 Figure 14: The MH-6LoRH Types 689 9. The BIER 6LoRH 691 (Note that the current contents of this section is a proof of concept 692 only; the details for this encoding need to be developed in parallel 693 with defining the semantics of a constrained version of BIER.) 695 The Bit Index Explicit Replication (BIER) 6LoRH (BIER-6LoRH) is an 696 Elective 6LoWPAN Routing Header that provides a variable-size 697 container for a BIER Bitmap. BIER can be used to route downwards a 698 RPL graph towards one or more LLN node, as discussed in the BIER 699 Architecture [I-D.wijnands-bier-architecture] specification. The 700 capability to parse the BIER Bitmap is necessary to forward the 701 packet so the Type cannot be ignored. 703 0 1 704 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+- ... -+ 706 |1|0|0| Size |6LoRHType12..19| Control Fields | bitmap | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+- ... -+ 709 Figure 15: The BIER-6LoRH 711 The Type for a BIER-6LoRH indicates the size of words used to build 712 the bitmap and whether the bitmap is operated as an uncompressed bit- 713 by-bit mapping, or as a Bloom filter. 715 In the bit-by-bit case, each bit is mapped in an unequivocal fashion 716 with a single addressable resource in the network. This may rapidly 717 lead to large bitmaps, and BIER allows to divide a network into 718 groups that partition the network so that a given bitmap is locally 719 significant to one group only. This specification allows to encode a 720 1-byte Group ID in the BIER-6LoRH Control Fields. 722 A Bloom Filter can be seen as a compression technique for the bitmap. 723 A Bloom Filter may generate false positives, which, in the case of 724 BIER, result in undue forwarding of a packet down a path where no 725 listener exists. 727 As an example, the Constrained-Cast [I-D.bergmann-bier-ccast] 728 specification employs Bloom Filters as a compact representation of a 729 match or non-match for elements in a large set. 731 In the case of a Bloom Filter, a number of Hash functions must be run 732 to obtain a multi-bit signature of an encoded element. This 733 specification allows to signal an Identifier of the Hash functions 734 being used to generate a certain bitmap, so as to enable a migration 735 scenario where Hash functions are renewed. A Hash ID is signaled as 736 a 1-byte value, and, depending on the Type, there may be up to 2 or 737 up to 8 Hash IDs passed in the BIER-6LoRH Control Fields associated 738 with a Bloom Filter bitmap, as follows: 740 +-----------+--------------+------------------+-----------+ 741 | Type | encoding | Control Fields | Word Size | 742 +-----------+--------------+------------------+-----------+ 743 | 12 | bit-by-bit | none | 32 bits | 744 | 13 | Bloom filter | 2* 1-byte HashID | 32 bits | 745 | 14 | bit-by-bit | none | 128 bits | 746 | 15 | Bloom filter | 8* 1-byte HashID | 128 bits | 747 | 16 | bit-by-bit | 1-byte GroupID | 128 bits | 748 +-----------+--------------+------------------+-----------+ 750 Figure 16: The BIER-6LoRH Types 752 In order to address a potentially large number of devices, the bitmap 753 may grow very large. Yet, the maximum frame size for a given MAC 754 layer may limit the number of bits that can be dedicated to routing. 755 The Size indicates the number of words in the bitmap minus one, so a 756 size of 0 means one word, a Size of 1 means 64 2 words, up to a size 757 of 31 which means 32 words. 759 10. Security Considerations 761 The security considerations of [RFC4944], [RFC6282], and [RFC6553] 762 apply. 764 Using a compressed format as opposed to the full inline RPL option is 765 logically equivalent and does not create an opening for a new threat 766 when compared to [RFC6553]. 768 11. IANA Considerations 770 This document creates a IANA registry for the 6LoWPAN Routing Header 771 Type, and assigns the following values: 773 0..4 : RH3-6LoRH [RFCthis] 775 5 : RPI-6LoRH [RFCthis] 777 6 : IPinIP-6LoRH [RFCthis] 779 8..11 : MH-6LoRH [RFCthis] 781 12..16 : BIER-6LoRH [RFCthis] 783 12. Acknowledgements 785 The author wishes to thank Martin Turon and Robert Cragie for 786 constructive contributions. The discussion in the 6man and roll 787 working groups also was helpful. 789 13. References 791 13.1. Normative References 793 [IEEE802154] 794 IEEE standard for Information Technology, "IEEE std. 795 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 796 and Physical Layer (PHY) Specifications for Low-Rate 797 Wireless Personal Area Networks", 2015. 799 [ISA100.11a] 800 ISA/ANSI, "Wireless Systems for Industrial Automation: 801 Process Control and Related Applications - ISA100.11a-2011 802 - IEC 62734", 2011, . 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, March 1997. 808 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 809 (IPv6) Specification", RFC 2460, December 1998. 811 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 812 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 813 September 2011. 815 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 816 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 817 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 818 Lossy Networks", RFC 6550, March 2012. 820 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 821 Protocol for Low-Power and Lossy Networks (RPL)", RFC 822 6552, March 2012. 824 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 825 Power and Lossy Networks (RPL) Option for Carrying RPL 826 Information in Data-Plane Datagrams", RFC 6553, March 827 2012. 829 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 830 Routing Header for Source Routes with the Routing Protocol 831 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 832 2012. 834 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 835 "Neighbor Discovery Optimization for IPv6 over Low-Power 836 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 837 November 2012. 839 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 840 Lossy Networks", RFC 7102, January 2014. 842 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 843 Constrained-Node Networks", RFC 7228, May 2014. 845 13.2. Informative References 847 [I-D.bergmann-bier-ccast] 848 Bergmann, O., Bormann, C., and S. Gerdes, "Constrained- 849 Cast: Source-Routed Multicast for RPL", draft-bergmann- 850 bier-ccast-00 (work in progress), November 2014. 852 [I-D.bormann-6lo-rpl-mesh] 853 Bormann, C., "NHC compression for RPL Packet Information", 854 draft-bormann-6lo-rpl-mesh-02 (work in progress), October 855 2014. 857 [I-D.ietf-6tisch-architecture] 858 Thubert, P., Watteyne, T., and R. Assimiti, "An 859 Architecture for IPv6 over the TSCH mode of IEEE 860 802.15.4e", draft-ietf-6tisch-architecture-04 (work in 861 progress), October 2014. 863 [I-D.ietf-6tisch-tsch] 864 Watteyne, T., Palattella, M., and L. Grieco, "Using 865 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 866 Statement and Goals", draft-ietf-6tisch-tsch-05 (work in 867 progress), January 2015. 869 [I-D.thubert-6lo-forwarding-fragments] 870 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 871 Recovery", draft-thubert-6lo-forwarding-fragments-02 (work 872 in progress), November 2014. 874 [I-D.thubert-6lo-rpl-nhc] 875 Thubert, P. and C. Bormann, "A compression mechanism for 876 the RPL option", draft-thubert-6lo-rpl-nhc-02 (work in 877 progress), October 2014. 879 [I-D.wijnands-bier-architecture] 880 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 881 S. Aldrin, "Multicast using Bit Index Explicit 882 Replication", draft-wijnands-bier-architecture-02 (work in 883 progress), December 2014. 885 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 886 "Transmission of IPv6 Packets over IEEE 802.15.4 887 Networks", RFC 4944, September 2007. 889 Authors' Addresses 891 Pascal Thubert (editor) 892 Cisco Systems 893 Village d'Entreprises Green Side 894 400, Avenue de Roumanille 895 Batiment T3 896 Biot - Sophia Antipolis 06410 897 FRANCE 899 Phone: +33 4 97 23 26 34 900 Email: pthubert@cisco.com 902 Carsten Bormann 903 Universitaet Bremen TZI 904 Postfach 330440 905 Bremen D-28359 906 Germany 908 Phone: +49-421-218-63921 909 Email: cabo@tzi.org 911 Laurent Toutain 912 Institut MINES TELECOM; TELECOM Bretagne 913 2 rue de la Chataigneraie 914 CS 17607 915 Cesson-Sevigne Cedex 35576 916 France 918 Email: Laurent.Toutain@telecom-bretagne.eu 919 Robert Cragie 920 ARM Ltd. 921 110 Fulbourn Road 922 Cambridge CB1 9NJ 923 UK 925 Email: robert.cragie@gridmerge.com