idnits 2.17.1 draft-thubert-6lo-routing-dispatch-01.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 (December 08, 2014) is 3428 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 738, but not defined == Unused Reference: 'I-D.bormann-6lo-rpl-mesh' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lo-rpl-nhc' is defined on line 831, 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-03 == 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-01 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: June 11, 2015 L. Toutain 7 IMT-TELECOM Bretagne 8 December 08, 2014 10 A Routing Header Dispatch for 6LoWPAN 11 draft-thubert-6lo-routing-dispatch-01 13 Abstract 15 This specification provides a new 6LoWPAN dispatch type for use in 16 Route-over and mixed Mesh-under and Route-over topologies, that 17 reuses the encoding of the mesh type defined in RFC 4944 for pure 18 Mesh-under topologies. This specification also defines a method to 19 compress RPL Option (RFC6553) information and Routing Header type 3 20 (RFC6554), an efficient IP-in-IP technique and opens the way for 21 further routing techniques. This extends 6LoWPAN Transmission of 22 IPv6 Packets (RFC4944), and is applicable to new link-layer types 23 where 6LoWPAN is being defined. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 11, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Updating RFC 4944 . . . . . . . . . . . . . . . . . . . . . . 5 62 4. General Format . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. The Routing Header type 3 (RH3) 6LoRH . . . . . . . . . . . . 7 64 6. The RPL Packet Information 6LoRH . . . . . . . . . . . . . . 9 65 6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 10 66 6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 10 67 6.3. The Overall RPI-6LoRH encoding . . . . . . . . . . . . . 11 68 7. The IP-in-IP 6LoRH . . . . . . . . . . . . . . . . . . . . . 13 69 8. The Mesh Header 6LoRH . . . . . . . . . . . . . . . . . . . . 14 70 9. The BIER 6LoRH . . . . . . . . . . . . . . . . . . . . . . . 15 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 76 13.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 The design of Low Power and Lossy Networks (LLNs) is generally 82 focused on saving energy, which is the most constrained resource of 83 all. The other constraints, such as the memory capacity and the duty 84 cycling of the LLN devices, derive from that primary concern. Energy 85 is often available from primary batteries that are expected to last 86 for years, or is scavenged from the environment in very limited 87 quantities. Any protocol that is intended for use in LLNs must be 88 designed with the primary concern of saving energy as a strict 89 requirement. 91 Controlling the amount of data transmission is one possible venue to 92 save energy. In a number of LLN standards, the frame size is limited 93 to much smaller values than the IPv6 maximum transmission unit (MTU) 94 of 1280 bytes. In particular, an LLN that relies on the classical 95 Physical Layer (PHY) of IEEE 802.14.5 [IEEE802154] is limited to 127 96 bytes per frame. The need to compress IPv6 packets over IEEE 97 802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work 98 (6LoWPAN-HC). 100 Innovative Route-over techniques have been and are still being 101 developed for routing inside a LLN. In a general fashion, such 102 techniques require additional information in the packet to provide 103 loop prevention and to indicate information such as flow 104 identification, source routing information, etc. 106 For reasons such as security and the capability to send ICMP errors 107 back to the source, an original packet must not be tampered with, and 108 any information that must be inserted in or removed from an IPv6 109 packet must be placed in an extra IP-in-IP encapsulation. This is 110 the case when the additional routing information is inserted by a 111 router on the path of a packet, for instance a mesh root, as opposed 112 to the source node. This is also the case when some routing 113 information must be removed from a packet that will flow outside the 114 LLN. 116 As an example, the Routing Protocol for Low Power and Lossy Networks 117 [RFC6550] (RPL) is designed to optimize the routing operations in 118 constrained LLNs. As part of this optimization, RPL requires the 119 addition of RPL Packet Information (RPI) in every packet, as defined 120 in Section 11.2 of [RFC6550]. 122 The RPL Option for Carrying RPL Information in Data-Plane Datagrams 123 [RFC6553] specification indicates how the RPI can be placed in a RPL 124 Option for use in an IPv6 Hop-by-Hop header. This representation 125 demands a total of 8 bytes when in most cases the actual RPI payload 126 requires only 19 bits. Since the Hop-by-Hop header must not flow 127 outside of the RPL domain, it must be removed from packets that leave 128 the domain, and be inserted in packets entering the domain. In both 129 cases, this operation implies an IP-in-IP encapsulation. 131 ------+--------- ^ 132 | Internet | 133 | | Native IPv6 134 +-----+ | 135 | | Border Router (RPL Root) ^ | ^ 136 | | | | | 137 +-----+ | | | IPv6 in 138 | | | | IPv6 139 o o o o | | | + RPI 140 o o o o o o o o o | | | or RH3 141 o o o o o o o o o o | | | 142 o o o o o o o o o | | | 143 o o o o o o o o v v v 144 o o o o 145 LLN 147 Figure 1: IP-in-IP Encapsulation within the LLN 149 Additionally, in the case of the Non-Storing Mode of Operation (MOP), 150 RPL requires a Routing Header type 3 (RH3) as defined in the IPv6 151 Routing Header for Source Routes with RPL [RFC6554] specification, 152 for all packets that are routed down a RPL graph. With Non-Storing 153 RPL, even if the source is a node in the same LLN, the packet must 154 first reach up the graph to the root so that the root can insert the 155 RH3 to go down the graph. In any fashion, whether the packet was 156 originated in a node in the LLN or outside the LLN, and regardless of 157 whether the packet stays within the LLN or not, as long as the source 158 of the packet is not the root itself, the source-routing operation 159 also implies an IP-in-IP encapsulation at the root to insert the RH3. 161 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 162 over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) 163 mode of operation of IEEE 802.14.5. The architecture requires the 164 use of both RPL and the 6lo adaptation layer framework ([RFC4944], 165 [RFC6282]) over IEEE 802.14.5. Because it inherits the constraints 166 on the frame size from the MAC layer, 6TiSCH cannot afford to spend 8 167 bytes per packet on the RPI. Hence the requirement for a 6LoWPAN 168 header compression of the RPI. 170 The type of information that needs to be present in a packet inside 171 the LLN but not outside of the LLN varies with the routing operation, 172 but there is overall a need for an extensible compression technique 173 that would simplify the IP-in-IP encapsulation, when needed, and 174 optimally compress existing routing artifacts found in LLNs. 176 This specification extends 6LoWPAN [RFC4944] and in particular reuses 177 the Mesh Header formats that are defined for the Mesh-under use cases 178 so as to carry routing information for Route-over use cases. The 179 specification includes the formats necessary for RPL and is 180 extensible for additional formats. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in 187 [RFC2119]. 189 The Terminology used in this document is consistent with and 190 incorporates that described in `Terminology in Low power And Lossy 191 Networks' [RFC7102] and [RFC6550]. 193 The terms Route-over and Mesh-under are defined in [RFC6775]. 195 Other terms in use in LLNs are found in [RFC7228]. 197 The term "byte" is used in its now customary sense as a synonym for 198 "octet". 200 3. Updating RFC 4944 202 Section 5.1 of the IPv6 over IEEE 802.15.4 [RFC4944] specification 203 defines various Dispatch Types and Headers, and in particular a Mesh 204 Header that corresponds to a pattern 10xxxxxx and effectively 205 consumes one third of the whole 6LoWPAN dispatch space for Mesh-under 206 specific applications. 208 This specification reuses the Dispatch space for Route-over and mixed 209 operations. This means that a device that use the Mesh Header as 210 specified in [RFC4944] should not be placed in a same network as a 211 device which operates per this update. This is generally not a 212 problem since a network is classically either Mesh-under OR Route- 213 over. 215 A new implementation of Mesh-under MAY support both types of 216 encoding, and if so, it SHOULD provide a management toggle to enable 217 either mode and it SHOULD use this specification as the default mode. 219 4. General Format 221 The 6LoWPAN Routing Header (6LoRH) reuses the bit patterns that are 222 defined in [RFC4944] for the Mesh Header, specifically the Dispatch 223 Value Bit Pattern of 10xxxxxx. It may contain source routing 224 information such as a compressed form of RH3, or other sorts of 225 routing information such as the RPL RPI, source and/or destination 226 address, and is extensible for future uses, with the given example of 227 BIER bitmap encoding in Section 9. 229 0 1 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ 232 |1|0|1| Length | Type | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ 234 <-- Length --> 235 I = 1 236 0 1 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ 239 |1|0|0| TSE | Type | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .... +-+ 241 <--implied length--> 242 I = 0 244 Figure 2: 6LoWPAN Routing Header 246 I Flag: 247 The 'I' flag is set to indicate that a 6LoWPAN Routing Header 248 may be ignored and skipped in parsing. If it is ignored, the 249 6LoRH is forwarded with no change inside the LLN. 251 TSE 252 Type Specific Extension. The meaning depends on the type, 253 which must be know of all the nodes. TSE can influence the 254 size of the implied length. 256 Length 257 length in bytes of the value part. 259 A 6LoWPAN Routing Header is shaped as a TLV. The first byte contains 260 an 'I' flag that is set if the 6LoRH can safely be ignored, and a 261 5-bit field which depends on the setting of the 'I' flag. 263 If the 'I' flag is set, the remainder of the first byte contains the 264 Length of the 6LoRH expressed in bytes, excluding the first 2 bytes. 265 This is done to enable a node to skip a 6LoRH that it does not 266 support and/or cannot parse, for instance if the Type is unknown. 268 If the 'I' flag is not set, then a node that does not support the 269 Type MUST drop the packet (Note that there is no provision for the 270 exchange of error messages; such a situation should be avoided by 271 judicious use of administrative control and/or capability 272 indications). 274 So when 'I' is not set, further parsing of the packet implies that 275 the Type is supported, and it is possible to encode a Type-Specific 276 Extension (TSE) in the remainder of the first octet. The 277 interpretation of the TSE depends on the Type field that follows. 278 For instance, it may be used to transport control bits, the number of 279 elements in an array, or the length of the remainder of the 6LoRH but 280 which may be expressed in a unit that is not byte. 282 The second byte contains the Type and eventually some flags which 283 depend on the Type. 285 One or more 6LoWPAN Routing Headers MAY be placed in a 6LoWPAN 286 packet. 288 Any 6LoWPAN Routing Headers MUST always be placed before the 289 LOWPAN_IPHC [RFC6282]. 291 A Fragmentation Type and Header [RFC4944] MAY be placed in any 292 position before, after or in between 6LoWPAN Routing Headers. [XXX: 293 Now what does that mean?] [YYY: I mean to say that we can have 0..n 294 6LoRH before a frag header, and 0..n 6LoRH after. If the frag header 295 is preceded by 1..n RH then the RH(s) may be used to route the 296 fragment] 298 Headers are processed in order so if 6LoWPAN Routing Headers located 299 before the Fragmentation Type and Header and / or the LOWPAN_IPHC are 300 sufficient to route a packet or a 6LoWPAN fragment over the LLN, then 301 there is no need to parse the LOWPAN_IPHC or to recompose the 302 fragmented packet at every LLN hop. 304 5. The Routing Header type 3 (RH3) 6LoRH 306 The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) provides a 307 compressed form for the Routing Header defined in [RFC6554] for use 308 by RPL routers. Routers that need to forward a packet with a 309 RH3-6LoRH are expected to be RPL routers and expected to support this 310 specification. If a non-RPL router receives a packet with a RPI- 311 6LoRH, this means that there was a routing error and the packet 312 should be dropped so the Type cannot be ignored. 314 0 1 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 317 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 320 Size indicates the number of compressed addresses 322 Figure 3: The RH3-6LoRH 324 The values for the RH3-6LoRH Type are an enumeration, 0 to 4. The 325 form of compression is indicated by the Type as follows: 327 +-----------+-----------+ 328 | Type | Size Unit | 329 +-----------+-----------+ 330 | 0 | 1 | 331 | 1 | 2 | 332 | 2 | 4 | 333 | 3 | 8 | 334 | 4 | 16 | 335 +-----------+-----------+ 337 Figure 4: The RH3-6LoRH Types 339 In the case of a RH3-6LoRH, the TSE field is used as a Size, which 340 encodes the number of hops minus 1; so a Size of 0 means one hop, and 341 the maximum that can be encoded is 32 hops. (If more than 32 hops 342 need to be expressed, a sequence of RH3-6LoRH can be employed.) 344 The next Hop is indicated in the first entry of the first RH3-6LoRH. 345 Upon reception, the entry is checked whether it refers to the 346 processing router itself. If it so, the entry is removed from the 347 RH3-6LoRH and the Size is decremented. If the Size is now zero, the 348 whole RH3-6LoRH is removed. If there is no more RH3-6LoRH, the 349 processing node is the last router on the way, which may or may not 350 be collocated with the final destination. 352 The last hop in the last RH3-6LoRH is the last router prior to the 353 destination in the LLN. So even when there is a RH3-6LoRH in the 354 frame, the address of the final destination is in the LoWPAN_IPHC 355 [RFC6282]. 357 If some bits of the first address in the RH3-6LoRH can be derived 358 from the final destination is in the LoWPAN_IPHC, then that address 359 may be compressed, otherwise is is expressed in full. Next addresses 360 only need to express the delta from the previous address. 362 All addresses in a RH3-6LoRH are compressed in a same fashion, down 363 to the same number of bytes per address. In order to get different 364 forms of compression, multiple consecutive RH3-6LoRH must be used. 366 6. The RPL Packet Information 6LoRH 368 [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) 369 as a set of fields that are to be added to the IP packets for the 370 purpose of Instance Identification, as well as Loop Avoidance and 371 Detection. 373 In particular, the SenderRank, which is the scalar metric computed by 374 an specialized Objective Function such as [RFC6552], indicates the 375 Rank of the sender and is modified at each hop. The SenderRank 376 allows to validate that the packet progresses in the expected 377 direction, either upwards or downwards, along the DODAG. 379 RPL defines the RPL Option for Carrying RPL Information in Data-Plane 380 Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 381 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes 382 per packet. 384 With [RFC6553], the RPL option is encoded as six Octets; it must be 385 placed in a Hop-by-Hop header that consumes two additional octets for 386 a total of eight. In order to limit its range to the inside the RPL 387 domain, the Hop-by-Hop header must be added to (or removed from) 388 packets that cross the border of the RPL domain. 390 The 8-bytes overhead is detrimental to the LLN operation, in 391 particular with regards to bandwidth and battery constraints. These 392 bytes may cause a containing frame to grow above maximum frame size, 393 leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn 394 cause even more energy spending and issues discussed in the LLN 395 Fragment Forwarding and Recovery 396 [I-D.thubert-6lo-forwarding-fragments]. 398 An additional overhead comes from the need, in certain cases, to add 399 an IP-in-IP encapsulation to carry the Hop-by-Hop header. This is 400 needed when the router that inserts the Hop-by-Hop header is not the 401 source of the packet, so that an error can be returned to the router. 402 This is also the case when a packet originated by a RPL node must be 403 stripped from the Hop-by-Hop header to be routed outside the RPL 404 domain. 406 This specification defines an IPinIP-6LoRH in Section 7 for that 407 purpose, but it must be noted that stripping a 6LoRH does not require 408 a manipulation of the packet in the LOWPAN_IPHC, and thus, if the 409 source address in the LOWPAN_IPHC is the node that inserted the 410 IPinIP-6LoRH then this alone does not mandate an IPinIP-6LoRH. 412 As a result, an RPL packet may bear only a RPI-6LoRH and no IPinIP- 413 6LoRH. In that case, the source and destination of the packet are 414 located in the LOWPAN_IPHC. 416 As with [RFC6553], the fields in the RPI include an 'O', an 'R', and 417 an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), 418 and a 16-bit SenderRank. 420 The remainder of this section defines the RPI-6LoRH, that is a new 421 6LoWPAN Routing Header designed to transport the RPI in 6LoWPAN LLNs. 423 6.1. Compressing the RPLInstanceID 425 RPL Instances are discussed in [RFC6550], Section 5. A number of 426 simple use cases will not require more than one instance, and in such 427 a case, the instance is expected to be the global Instance 0. A 428 global RPLInstanceID is encoded in a RPLInstanceID field as follows: 430 0 1 2 3 4 5 6 7 431 +-+-+-+-+-+-+-+-+ 432 |0| ID | Global RPLInstanceID in 0..127 433 +-+-+-+-+-+-+-+-+ 435 Figure 5: RPLInstanceID Field Format for Global Instances 437 For the particular case of the global Instance 0, the RPLInstanceID 438 field is all zeros. This specification allows to elide a 439 RPLInstanceID field that is all zeros, and defines a I flag that, 440 when set, signals that the field is elided. 442 6.2. Compressing the SenderRank 444 The SenderRank is the result of the DAGRank operation on the rank of 445 the sender; here the DAGRank operation is defined in [RFC6550], 446 Section 3.5.1, as: 448 DAGRank(rank) = floor(rank/MinHopRankIncrease) 450 If MinHopRankIncrease is set to a multiple of 256, the least 451 significant 8 bits of the SenderRank will be all zeroes; by eliding 452 those, the SenderRank can be compressed into a single byte. This 453 idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE 454 as 256 and in [RFC6552] that defaults MinHopRankIncrease to 455 DEFAULT_MIN_HOP_RANK_INCREASE. 457 This specification allows to encode the SenderRank as either one or 458 two bytes, and defines a K flag that, when set, signals that a single 459 byte is used. 461 6.3. The Overall RPI-6LoRH encoding 463 The RPI-6LoRH provides a compressed form for the RPL RPI. Routers 464 that need to forward a packet with a RPI-6LoRH are expected to be RPL 465 routers and expected to support this specification. If a non-RPL 466 router receives a packet with a RPI-6LoRH, this means that there was 467 a routing error and the packet should be dropped so the Type cannot 468 be ignored. 470 Since the I flag is not set, the TSE field does not need to be a 471 length expressed in bytes. The field is fully reused for control 472 bits so as to encode the O, R and F flags from the RPI, and the I and 473 K flags that indicate the compression that is taking place. 475 The Type for the RPI-6LoRH is 5. 477 The RPI-6LoRH is immediately followed by the RPLInstanceID field, 478 unless that field is fully elided, and then the SenderRank, which is 479 either compressed into one byte or fully in-lined as the whole 2 480 bytes. The I and K flags in the RPI-6LoRH indicate whether the 481 RPLInstanceID is elided and/or the SenderRank is compressed and 482 depending on these bits, the Length of the RPI-6LoRH may vary as 483 described hereafter. 485 0 1 2 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 488 |1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+ 491 Figure 6: The Generic RPI-6LoRH Format 493 O, R, and F bits: 494 The O, R, and F bits as defined in [RFC6550], Section 11.2. 496 I bit: 497 If it is set, the Instance ID is elided and the RPLInstanceID 498 is the Global RPLInstanceID 0. If it is not set, the octet 499 immediately following the type field contains the RPLInstanceID 500 as specified in [RFC6550] section 5.1. 502 K bit: 504 If it is set, the SenderRank is be compressed into one octet, 505 and the lowest significant octet is elided. If it is not set, 506 the SenderRank, is fully inlined as 2 octets. 508 In Figure 7, the RPLInstanceID is the Global RPLInstanceID 0, and the 509 MinHopRankIncrease is a multiple of 256 so the least significant byte 510 is all zeros and can be elided: 512 0 1 2 513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 I=1, K=1 519 Figure 7: The most compressed RPI-6LoRH 521 In Figure 8, the RPLInstanceID is the Global RPLInstanceID 0, but 522 both bytes of the SenderRank are significant so it can not be 523 compressed: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 I=1, K=0 532 Figure 8: Eliding the RPLInstanceID 534 In Figure 9, the RPLInstanceID is not the Global RPLInstanceID 0, and 535 the MinHopRankIncrease is a multiple of 256: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 I=0, K=1 544 Figure 9: Compressing SenderRank 546 In Figure 10, the RPLInstanceID is not the Global RPLInstanceID 0, 547 and both bytes of the SenderRank are significant: 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 |1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-... 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 ...-Rank | 555 +-+-+-+-+-+-+-+-+ 556 I=0, K=0 558 Figure 10: Least compressed form of RPI-6LoRH 560 A typical packet in RPL non-storing mode going down the RPL graph 561 requires an IPinIP encapsulating the RH3, whereas the RPI is usually 562 omitted, unless it is important to indicate the RPLInstanceID. To 563 match this structure, an optimized IPinIP 6LoRH is defined in 564 Section 7. 566 7. The IP-in-IP 6LoRH 568 The IP-in-IP 6LoRH IPinIP-6LoRH provides a compressed form for the 569 encapsulating IPv6 Header in the case of an IP-in-IP encapsulation. 571 An IPinIP encapsulation is used to insert a field such as a Routing 572 Header or an RPI at a router that is not the source of the packet. 573 In order to send an error back regarding the inserted field, the 574 address of the router that performs the insertion must be provided. 576 The encapsulation can also enable a router down the path removing a 577 field such as the RPI, but this can be done in the compressed form by 578 removing the RPI-6LoRH, so an IPinIP-6LoRH encapsulation is not 579 required for that sole purpose. 581 This field is not critical for routing so the Type can be ignored, 582 and the TSE field contains the Length in bytes. 584 0 1 2 585 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 587 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 590 Figure 11: The IPinIP-6LoRH 592 The Length of an IPinIP-6LoRH is expressed in bytes and MUST be at 593 least 1, to indicate a Hop Limit (HL), that is decremented at each 594 hop. When the HL reaches 0, the packet is dropped per [RFC2460] 595 If the Length of an IPinIP-6LoRH is exactly 1, then the Encapsulator 596 Address is elided, which means that the Encapsulator is a well-known 597 router, for instance the root in a RPL graph. 599 If the Length of an IPinIP-6LoRH is strictly more than 1, then an 600 Encapsulator Address is placed in a compressed form after the Hop 601 Limit field. The value of the Length indicates which compression is 602 performed on the Encapsulator Address. For instance, a Size of 3 603 indicates that the Encapsulator Address is compressed to 2 bytes. 605 8. The Mesh Header 6LoRH 607 The Mesh Header 6LoRH (MH-6LoRH) provides an alternate form for the 608 Mesh Addressing Type and Header defined in [RFC4944] with the same 609 semantics. 611 The MH-6LoRH is introduced as replacement for use in potentially 612 mixed Route_Over and Mesh-under environments. LLN nodes that need to 613 forward a packet with a MH-6LoRH are expected to support this 614 specification. If a router that supports only Route-over receives a 615 packet with a MH-6LoRH, this means that there was a routing error and 616 the packet should be dropped, so the Type cannot be ignored. 618 The HopsLft field defined in [RFC4944] is encoded in the TSE, so this 619 specification doubles the potential number of hops vs. [RFC4944]. 621 The HopsLft value of 0x1F is reserved and signifies an 8-bit Deep 622 Hops Left field immediately following the Type, and allows a source 623 node to specify a hop limit greater than 30 hops. 625 0 1 626 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 628 |1|0|0| HopsLft |6LoRHType 8..11| originator address, final address 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 631 Figure 12: The MH-6LoRH 633 The V and F flags defined in [RFC4944] are encoded in the MH-6LoRH 634 Type as follows: 636 +-----------+-------+-------+ 637 | Type | V | F | 638 +-----------+-------+-------+ 639 | 8 | 0 | 0 | 640 | 9 | 0 | 1 | 641 | 10 | 1 | 0 | 642 | 11 | 1 | 1 | 643 +-----------+-------+-------+ 645 Figure 13: The MH-6LoRH Types 647 9. The BIER 6LoRH 649 (Note that the current contents of this section is a proof of concept 650 only; the details for this encoding need to be developed in parallel 651 with defining the semantics of a constrained version of BIER.) 653 The Bit Index Explicit Replication (BIER) 6LoRH (BIER-6LoRH) provides 654 a variable-size container for a BIER Bitmap that is used to route 655 towards one or more LLN node, as discussed in the BIER Architecture 656 [I-D.wijnands-bier-architecture] specification. The capability to 657 parse the BIER Bitmap is necessary to forward the packet so the Type 658 cannot be ignored. 660 0 1 661 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+- ... -+ 663 |1|0|0| Size |6LoRHType12..19| Control Fields | bitmap | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+- ... -+ 666 Figure 14: The BIER-6LoRH 668 The Type for a BIER-6LoRH indicates the size of words used to build 669 the bitmap and whether the bitmap is operated as an uncompressed bit- 670 by-bit mapping, or as a Bloom filter. 672 In the bit-by-bit case, each bit is mapped in an unequivocal fashion 673 with a single addressable resource in the network. This may rapidly 674 lead to large bitmaps, and BIER allows to divide a network into 675 groups that partition the network so that a given bitmap is locally 676 significant to one group only. This specification allows to encode a 677 1-byte Group ID in the BIER-6LoRH Control Fields. 679 A Bloom Filter can be seen as a compression technique for the bitmap. 680 A Bloom Filter may generate false positives, which, in the case of 681 BIER, result in undue forwarding of a packet down a path where no 682 listener exists. 684 As an example, the Constrained-Cast [I-D.bergmann-bier-ccast] 685 specification employs Bloom Filters as a compact representation of a 686 match or non-match for elements in a large set. 688 In the case of a Bloom Filter, a number of Hash functions must be run 689 to obtain a multi-bit signature of an encoded element. This 690 specification allows to signal an Identifier of the Hash functions 691 being used to generate a certain bitmap, so as to enable a migration 692 scenario where Hash functions are renewed. A Hash ID is signaled as 693 a 1-byte value, and, depending on the Type, there may be up to 2 or 694 up to 8 Hash IDs passed in the BIER-6LoRH Control Fields associated 695 with a Bloom Filter bitmap, as follows: 697 +-----------+--------------+------------------+-----------+ 698 | Type | encoding | Control Fields | Word Size | 699 +-----------+--------------+------------------+-----------+ 700 | 12 | bit-by-bit | none | 32 bits | 701 | 13 | Bloom filter | 2* 1-byte HashID | 32 bits | 702 | 14 | bit-by-bit | none | 128 bits | 703 | 15 | Bloom filter | 8* 1-byte HashID | 128 bits | 704 | 16 | bit-by-bit | 1-byte GroupID | 128 bits | 705 +-----------+--------------+------------------+-----------+ 707 Figure 15: The BIER-6LoRH Types 709 In order to address a potentially large number of devices, the bitmap 710 may grow very large. Yet, the maximum frame size for a given MAC 711 layer may limit the number of bits that can be dedicated to routing. 712 The Size indicates the number of words in the bitmap minus one, so a 713 size of 0 means one word, a Size of 1 means 64 2 words, up to a size 714 of 31 which means 32 words. 716 10. Security Considerations 718 The security considerations of [RFC4944], [RFC6282], and [RFC6553] 719 apply. 721 Using a compressed format as opposed to the full inline RPL option is 722 logically equivalent and does not create an opening for a new threat 723 when compared to [RFC6553]. 725 11. IANA Considerations 727 This document creates a IANA registry for the 6LoWPAN Routing Header 728 Type, and assigns the following values: 730 0..4 : RH3-6LoRH [RFCthis] 732 5 : RPI-6LoRH [RFCthis] 734 6 : IPinIP-6LoRH [RFCthis] 736 8..11 : MH-6LoRH [RFCthis] 738 12..16 : BIER-6LoRH [RFCthis] 740 12. Acknowledgements 742 The author wishes to thank Martin Turon and Robert Cragie for 743 constructive contributions. The discussion in the 6man and roll 744 working groups also was helpful. 746 13. References 748 13.1. Normative References 750 [IEEE802154] 751 IEEE standard for Information Technology, "IEEE std. 752 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 753 and Physical Layer (PHY) Specifications for Low-Rate 754 Wireless Personal Area Networks", 2015. 756 [ISA100.11a] 757 ISA/ANSI, "Wireless Systems for Industrial Automation: 758 Process Control and Related Applications - ISA100.11a-2011 759 - IEC 62734", 2011, . 762 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 763 Requirement Levels", BCP 14, RFC 2119, March 1997. 765 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 766 (IPv6) Specification", RFC 2460, December 1998. 768 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 769 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 770 September 2011. 772 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 773 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 774 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 775 Lossy Networks", RFC 6550, March 2012. 777 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 778 Protocol for Low-Power and Lossy Networks (RPL)", RFC 779 6552, March 2012. 781 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 782 Power and Lossy Networks (RPL) Option for Carrying RPL 783 Information in Data-Plane Datagrams", RFC 6553, March 784 2012. 786 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 787 Routing Header for Source Routes with the Routing Protocol 788 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 789 2012. 791 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 792 "Neighbor Discovery Optimization for IPv6 over Low-Power 793 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 794 November 2012. 796 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 797 Lossy Networks", RFC 7102, January 2014. 799 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 800 Constrained-Node Networks", RFC 7228, May 2014. 802 13.2. Informative References 804 [I-D.bergmann-bier-ccast] 805 Bergmann, O., Bormann, C., and S. Gerdes, "Constrained- 806 Cast: Source-Routed Multicast for RPL", draft-bergmann- 807 bier-ccast-00 (work in progress), November 2014. 809 [I-D.bormann-6lo-rpl-mesh] 810 Bormann, C., "NHC compression for RPL Packet Information", 811 draft-bormann-6lo-rpl-mesh-02 (work in progress), October 812 2014. 814 [I-D.ietf-6tisch-architecture] 815 Thubert, P., Watteyne, T., and R. Assimiti, "An 816 Architecture for IPv6 over the TSCH mode of IEEE 817 802.15.4e", draft-ietf-6tisch-architecture-04 (work in 818 progress), October 2014. 820 [I-D.ietf-6tisch-tsch] 821 Watteyne, T., Palattella, M., and L. Grieco, "Using 822 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 823 Statement and Goals", draft-ietf-6tisch-tsch-03 (work in 824 progress), October 2014. 826 [I-D.thubert-6lo-forwarding-fragments] 827 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 828 Recovery", draft-thubert-6lo-forwarding-fragments-02 (work 829 in progress), November 2014. 831 [I-D.thubert-6lo-rpl-nhc] 832 Thubert, P. and C. Bormann, "A compression mechanism for 833 the RPL option", draft-thubert-6lo-rpl-nhc-02 (work in 834 progress), October 2014. 836 [I-D.wijnands-bier-architecture] 837 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 838 S. Aldrin, "Multicast using Bit Index Explicit 839 Replication", draft-wijnands-bier-architecture-01 (work in 840 progress), October 2014. 842 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 843 "Transmission of IPv6 Packets over IEEE 802.15.4 844 Networks", RFC 4944, September 2007. 846 Authors' Addresses 848 Pascal Thubert (editor) 849 Cisco Systems 850 Village d'Entreprises Green Side 851 400, Avenue de Roumanille 852 Batiment T3 853 Biot - Sophia Antipolis 06410 854 FRANCE 856 Phone: +33 4 97 23 26 34 857 Email: pthubert@cisco.com 859 Carsten Bormann 860 Universitaet Bremen TZI 861 Postfach 330440 862 Bremen D-28359 863 Germany 865 Phone: +49-421-218-63921 866 Email: cabo@tzi.org 867 Laurent Toutain 868 Institut MINES TELECOM; TELECOM Bretagne 869 2 rue de la Chataigneraie 870 CS 17607 871 Cesson-Sevigne Cedex 35576 872 France 874 Email: Laurent.Toutain@telecom-bretagne.eu