idnits 2.17.1 draft-thubert-6lo-rpl-nhc-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 RFC6282, but the abstract doesn't seem to directly say this. It does mention RFC6282 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 RFC6282, updated by this document, for RFC5378 checks: 2008-10-08) -- 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 (October 24, 2014) is 3466 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 486, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-03 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-02 Summary: 1 error (**), 0 flaws (~~), 4 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: 6282 (if approved) C. Bormann 5 Intended status: Standards Track TZI 6 Expires: April 27, 2015 October 24, 2014 8 A compression mechanism for the RPL option 9 draft-thubert-6lo-rpl-nhc-02 11 Abstract 13 This specification defines the RPL Packet Information (RPI) NHC 14 compression, a method to compress RPL Option (RFC6553) information 15 within 6LoWPAN-style ("6lo") adaptation layers. This extends 6LoWPAN 16 Header Compression (RFC6282), saving up to 48 bits in each frame 17 compared to the uncompressed form in RFC 6553. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 27, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Updating RFC 6282 . . . . . . . . . . . . . . . . . . . . . . 4 56 4. The RPL Packet Information NHC . . . . . . . . . . . . . . . 4 57 4.1. Compressing the RPLInstanceId . . . . . . . . . . . . . . 5 58 4.2. Compressing the SenderRank . . . . . . . . . . . . . . . 5 59 4.3. The RPI_NHC encoding . . . . . . . . . . . . . . . . . . 5 60 4.3.1. The Greedy Approach . . . . . . . . . . . . . . . . . 7 61 4.3.2. The Conservative Approach . . . . . . . . . . . . . . 7 62 4.3.3. The Efficient Approach . . . . . . . . . . . . . . . 8 63 4.3.3.1. The NHC escape mechanism . . . . . . . . . . . . 8 64 4.3.3.2. RPI_NHC Encoding . . . . . . . . . . . . . . . . 9 65 4.3.3.3. Operation . . . . . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 The design of Low Power and Lossy Networks (LLNs) is generally 77 focused on saving energy, which is the most constrained resource of 78 all. The other constraints, such as the memory capacity and the duty 79 cycling of the LLN devices, derive from that primary concern. Energy 80 is typically available from batteries that are expected to last for 81 years, or scavenged from the environment in very limited quantities. 82 Any protocol that is intended for use in LLNs must be designed with 83 the primary concern of saving energy as a strict requirement. 85 Controlling the amount of data transmission is one possible venue to 86 save energy. In a number of LLN standards, the frame size is limited 87 to much smaller values than the IPv6 maximum transmission unit (MTU) 88 of 1280 bytes. In particular, an LLN that relies on the classical 89 Physical Layer (PHY) of IEEE 802.14.5 [IEEE802154] is limited to 127 90 bytes per frame. The need to compress IPv6 packets over IEEE 91 802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work 92 (6LoWPAN-HC). 94 The Routing Protocol for Low Power and Lossy Networks [RFC6550] (RPL) 95 is designed to optimize the routing operations in constrained LLNs. 97 As part of this optimization, RPL requires the addition of RPL Packet 98 Information (RPI) in every packet, as defined in Section 11.2 of 99 [RFC6550]. 101 ------+--------- ^ 102 | Internet | 103 | | Native IPv6 104 +-----+ | 105 | | Border Router (RPL Root) ^ | ^ 106 | | | | | 107 +-----+ | | | IPv6 in 108 | | | | IPv6 + RPI 109 o o o o | | | 110 o o o o o o o o o | | | 111 o o o o o o o o o o | | | 112 o o o o o o o o o | | | 113 o o o o o o o o v v v 114 o o o o 115 LLN 117 Figure 1: IP-in-IP Encapsulation within the LLN 119 The RPI is used to tag the packet with the RPL Instance ID and other 120 information that RPL requires for its operation within the RPL 121 domain. In particular, the SenderRank, which is the scalar metric 122 computed by an specialized Objective Function such as [RFC6552], 123 indicates the Rank of the sender and is modified at each hop. The 124 SenderRank allows to validate that the packet progresses in the 125 expected direction, either upwards or downwards, along the DODAG. 127 RPL defines the RPL Option for Carrying RPL Information in Data-Plane 128 Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6 129 Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes 130 per packet. 132 6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6 133 over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (TSCH) 134 mode of operation of IEEE 802.14.5. The architecture requires the 135 use of both 6LoWPAN HC and RPL over IEEE 802.14.5. Because it 136 inherits the constraints on the frame size from the MAC layer, 6TiSCH 137 cannot afford to spend 8 bytes per packet on the RPI. Hence the 138 requirement for a 6LoWPAN header compression of the RPI. 140 This specification extends the 6lo adaptation layer framework 141 ([RFC4944], [RFC6282]) to carry the same information in a 6LoWPAN RPL 142 Packet Information (RPI) NHC Next-header compression (NHC) header, 143 usually eliminating the Hop-by-Hop Options Header saving up to six 144 bytes per packet. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 The Terminology used in this document is consistent with and 153 incorporates that described in `Terminology in Low power And Lossy 154 Networks' [RFC7102] and [RFC6550]. 156 The term "byte" is used in its now customary sense as a synonym for 157 "octet". 159 3. Updating RFC 6282 161 This specification proposes a new 6LoWPAN Next Header Compression 162 (NHC) for the RPL option [RFC6553], called RPI_NHC, to be placed in a 163 packet that is compressed per [RFC6282]. 165 It updates [RFC6282] in that the "necessary property of encoding 166 headers using LOWPAN_NHC" becomes that "the immediately preceding 167 header must be encoded using either LOWPAN_IPHC, RPI_NHC or 168 LOWPAN_NHC". 170 Additionally, the necessary property of encoding headers using 171 RPI_NHC is that the immediately preceding header must be encoded 172 using either LOWPAN_IPHC or LOWPAN_NHC. 174 (Discuss: Is this really an update of RFC 6282 or a straightforward 175 addition to it?) 177 4. The RPL Packet Information NHC 179 [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI) 180 as a set of fields that are to be added to the IP packets for the 181 purpose of Instance Identification, as well as Loop Avoidance and 182 Detection. 184 [RFC6553] defines an encoding for the RPI as a RPL option located in 185 the IPv6 Hop-by-hop Option Header. The present NHC compression 186 mechanism compresses IPv6 Hop-by-hop Headers that contain only that 187 RPL option. 189 The fields in the RPI include an 'O', an 'R', and an 'F' bit, an 190 8-bit RPLInstanceID (with some internal structure), and a 16-bit 191 SenderRank. 193 This section defines the format of the RPL Packet Information NHC 194 (RPI_NHC) that is used to compress the RPI in 6LoWPAN networks. 196 4.1. Compressing the RPLInstanceId 198 RPL Instances are discussed in [RFC6550], Section 5. A number of 199 simple use cases will not require more than one instance, and in such 200 a case, the instance is expected to be the global Instance 0. A 201 global RPLInstanceID is encoded in a RPLInstanceID field as follows: 203 0 1 2 3 4 5 6 7 204 +-+-+-+-+-+-+-+-+ 205 |0| ID | Global RPLInstanceID in 0..127 206 +-+-+-+-+-+-+-+-+ 208 Figure 2: RPLInstanceID Field Format for Global Instances 210 For the particular case of the global Instance 0, the RPLInstanceID 211 field is all zeroes. This specification allows to elide a 212 RPLInstanceID field that is all zeroes, and defines a 'I' flag that, 213 when set, signals that the field is elided. 215 4.2. Compressing the SenderRank 217 The SenderRank is the result of the DAGRank operation on the rank of 218 the sender; here the DAGRank operation is defined in [RFC6550], 219 Section 3.5.1, as: 221 DAGRank(rank) = floor(rank/MinHopRankIncrease) 223 If MinHopRankIncrease is set to a multiple of 256, the least 224 significant 8 bits of the SenderRank will be all zeroes; by eliding 225 those, the SenderRank can be compressed into a single byte. This 226 idea is used in [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE 227 as 256 and in [RFC6552] that defaults MinHopRankIncrease to 228 DEFAULT_MIN_HOP_RANK_INCREASE. 230 This specification allows to encode the SenderRank as either one or 231 two bytes, and defines a 'K' flag that, when set, signals that a 232 single byte is used. 234 4.3. The RPI_NHC encoding 236 [RFC6553] defines an encoding for the RPL information as a RPL Option 237 located in an IPv6 Hop-by-Hop Option Header. The RPI_NHC provides a 238 compressed form for that information and is constructed as follows: 240 The RPI_NHC is immediately followed by the RPLInstanceID, unless that 241 is elided (I=1), and then the SenderRank, which is either compressed 242 into one byte (K=1) or fully inlined as the whole 2 bytes (K=0). 243 Bits in the RPI_NHC indicate whether the RPLInstanceID is elided and/ 244 or the SenderRank is compressed: 246 O, R, and F bits: The O, R, and F bits as defined in [RFC6550], 247 Section 11.2. 249 NH: 1-bit flag. The Next Header (NH) bit is defined in [RFC6282], 250 Section 4.2, and it is set to indicate that the next header is 251 encoded using LOWPAN_NHC 253 I: 1-bit flag. If it is set, the Instance ID is elided and the 254 RPLInstanceID is the Global RPLInstanceID 0. If it is not set, 255 the byte immediately following the RPI_NHC contains the 256 RPLInstanceID as specified in [RFC6550], Section 5.1. 258 K: 1-bit flag. If it is set, the SenderRank is compressed into 259 one byte, and the least significant byte is elided. If it is 260 not set, the SenderRank is fully inlined as 2 bytes. 262 In Figure 3, the RPLInstanceID is the Global RPLInstanceID 0, and the 263 MinHopRankIncrease is a multiple of 256 so the least significant byte 264 is all zeroes and can be elided: 266 0 1 267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | NHC: I=1, K=1 | SenderRank | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3: The most compressed RPI_NHC 274 In Figure 4, the RPLInstanceID is the Global RPLInstanceID 0, but 275 both bytes of the SenderRank are significant so it can not be 276 compressed: 278 0 1 2 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | NHC: I=1, K=0 | SenderRank | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 4: Eliding the RPLInstanceID 286 In Figure 5, the RPLInstanceID is not the Global RPLInstanceID 0, and 287 the MinHopRankIncrease is a multiple of 256: 289 0 1 2 290 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | NHC: I=0, K=1 | RPLInstanceID | SenderRank | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 5: Compressing SenderRank 297 In Figure 6, the RPLInstanceID is not the Global RPLInstanceID 0, and 298 both bytes of the SenderRank are significant: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | NHC: I=0, K=0 | RPLInstanceID | SenderRank | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 6: Least compressed form of RPI_NHC 308 The next sections provide alternatives for format of the RPI_NHC. 310 4.3.1. The Greedy Approach 312 The RPI_NHC is constructed as follows: 314 0 1 2 3 4 5 6 7 315 +---+---+---+---+---+---+---+---+ 316 | 1 | 0 | I | K | O | R | F |NH | 317 +---+---+---+---+---+---+---+---+ 319 Figure 7: The RPI_NHC, Greedy Version 321 Depending on the RPLInstanceID and the MinHopRankIncrease, the 322 proposed format thus squeezes the RPL information into 16 to 32 bits, 323 which compares to 64 bits when using a Hop-by-hop option with the RPL 324 option as specified in [RFC6553]. 326 (This is called the "greedy" approach as it consumes 1/4 of the NHC 327 space just for the RPI compression.) 329 4.3.2. The Conservative Approach 331 In this approach, the encoding of the RPL Packet Information takes 332 two bytes: one byte to indicate the NH type, and then one byte to 333 signal the compressed information. 335 The NH type is indicated in an extension to existing LOWPAN_NHC 336 encodings. Section 4.2 of [RFC6553] defines LOWPAN_NHC encodings for 337 IPv6 Extension Headers as in Figure 8: 339 0 1 2 3 4 5 6 7 340 +---+---+---+---+---+---+---+---+ 341 | 1 | 1 | 1 | 0 | EID |NH | 342 +---+---+---+---+---+---+---+---+ 344 Figure 8: IPv6 Extension Header Encoding 346 Values 5 and 6 of the IPv6 Extension Header ID (EID) are still 347 reserved. This specification uses EID of 5 to indicate that the next 348 byte is a RPI_NHC. The RPI_NHC is constructed as shown in Figure 9: 350 0 1 2 3 4 5 6 7 351 +---+---+---+---+---+---+---+---+ 352 | I | K | O | R | F | reserved | 353 +---+---+---+---+---+---+---+---+ 355 Figure 9: The RPI_NHC, Conservative Version 357 The bits 5 to 7 of the RPI_NHC are reserved for future use and MUST 358 be sent as zero. 360 (This is called the "conservative" approach as it consumes only 1/256 361 of the NHC space.) 363 4.3.3. The Efficient Approach 365 4.3.3.1. The NHC escape mechanism 367 The NHC space of [RFC6282] is limited to 256 code points. For the 368 case some infrequent bit combinations do not fit into the 256 code 369 points, this specification assigns four code points: 371 0 1 2 3 4 5 6 7 372 +---+---+---+---+---+---+---+---+ 373 | 0 | 1 | 0 | 0 | 0 | 1 | X | Y | 374 +---+---+---+---+---+---+---+---+ 376 Figure 10: NHC Escape Codes 378 Each NHC escape code is followed by a further NHC code point. The 379 latter MUST be a code point for which special semantics for a 380 preceding escape code are defined, i.e., an escape code MUST NOT be 381 used in front of an NHC code point that does not define special 382 semantics for this escape code. 384 An escape code followed by another escape code supplies additional 385 semantics; again, a sequence of such escape codes MUST NOT be used 386 unless the final NHC code following this sequence defines the 387 semantics for the specific sequence. 389 4.3.3.2. RPI_NHC Encoding 391 The RPI_NHC provides a compressed form for the RPI and is constructed 392 as follows: 394 0 1 2 3 4 5 6 7 395 +---+---+---+---+---+---+---+---+ 396 | 1 | 0 | 0 | 0 | O | I | K |NH | 397 +---+---+---+---+---+---+---+---+ 399 Figure 11: RPI NHC, efficient version 401 The R and F bits, as defined in [RFC6550], Section 11.2, are 402 represented as follows: 404 If R=0 and F=0, the NHC code is used as defined above. If either is 405 non-zero, a single escape code with X=R and Y=F is prepended in front 406 of the NHC code. (An escape code with X=0 and Y=0 MUST NOT be used 407 with RPI_NHC. A sequence of two or more escape codes MUST NOT be 408 used with RPI_NHC.) 410 Depending on the RPLInstanceID and the MinHopRankIncrease, the 411 proposed format thus squeezes the RPI into 16 to 40 bits, which 412 compares to 64 bits when using a Hop-by-hop option with the RPL 413 option as specified in [RFC6553]. 415 (This is called the "efficient" approach as it consumes only 1/16 of 416 the NHC space, but, depending on the frequency of set R or set F 417 flags, is almost as efficient as the greedy approach.) 419 4.3.3.3. Operation 421 A 6lo compressor that is about to create either an RFC 6282 IPHC 422 header [RFC6282] or a Frag1 header [RFC4944] and finds a Hop-by-Hop 423 Options header [RFC2460] with an RPL Option [RFC6553] in it, performs 424 the following checks: 426 1. Does the compression scheme apply? I.e.: 428 A. is no sub-tlv present in the RPL Option? 430 B. is the RPL Option the only option in the Hop-by-Hop Options 431 header? 433 2. Does the additional compression for I=1 apply? I.e.: is 434 RPLInstanceID == 0? 436 3. Does the additional compression for K=1 apply? I.e.: is 437 SenderRank < 256? 439 4. Is both R=0 and F=0, or do we need an escape code? 441 If check 1 succeeds, the compressor removes the Hop-by-Hop Options 442 header (replacing the zero-valued next header field in the IPv6 443 header with the value of the next header field of the Hop-by-Hop 444 Options header), and, depending on the outcome of check 2 and 3, 445 generates an RPI_NHC Header with I and K set from the payload 446 information in the RPL Option. If one or both of R and F are non- 447 zero (check 4), it precedes the first byte in the RPI_NHC header with 448 an escape code with X=R and Y=F. It then continues generating the 449 RFC 6282 IPHC or RFC 4944 Frag1 header, filling in the continuation 450 of the RPL Information header as defined in Section 4.3.3.2. 452 A 6lo decompressor that encounters a RPL Information header reverses 453 this process, creating a Hop-by-Hop Options header with a single RPL 454 Option carrying the information in the RPL Information header. 456 5. Security Considerations 458 The security considerations of [RFC4944], [RFC6282], and [RFC6553] 459 apply. 461 Using a compressed format as opposed to the full inline RPL option is 462 logically equivalent and does not create an opening for a new threat 463 when compared to [RFC6553]. 465 6. IANA Considerations 467 (greedy variant:) 469 This document updates IANA registry for the LOWPAN_NHC defined in 470 [RFC6282] and assigns the previously unassigned: 472 10IKORFN: RPL Information [RFCthis] 474 Capital letters in bit positions represent class-specific bit 475 assignments. IKORF represents variables specific to RPL Information 476 compression defined in Section 4. N indicates whether or not 477 additional LOWPAN_NHC encodings follow, as defined in Section 4.2 of 478 [RFC6553]. 480 (efficient variant:) 481 This draft requests IANA to assign the following LOWPAN_NHC types in 482 the "IPv6 Low Power Personal Area Network Parameters" registry: 484 010001XY: Escape X=0/Y=0 to X=1/Y=1 [RFCthis] 486 1000IOKN: RPL Information [RFCthis] 488 7. Acknowledgements 490 The author wishes to thank Laurent Toutain for suggesting this work 491 and and Martin Turon for his constructive contributions. Ralph Droms 492 supplied a number of helpful comments on the -00 draft of 493 [I-D.bormann-6lo-rpl-mesh], which was superseded by the present 494 document, turning into the "efficient approach". The discussion in 495 the 6man and roll working groups also was helpful. 497 8. References 499 8.1. Normative References 501 [IEEE802154] 502 IEEE standard for Information Technology, "IEEE std. 503 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 504 and Physical Layer (PHY) Specifications for Low-Rate 505 Wireless Personal Area Networks", June 2011. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 511 (IPv6) Specification", RFC 2460, December 1998. 513 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 514 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 515 September 2011. 517 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 518 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 519 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 520 Lossy Networks", RFC 6550, March 2012. 522 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 523 Protocol for Low-Power and Lossy Networks (RPL)", RFC 524 6552, March 2012. 526 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 527 Power and Lossy Networks (RPL) Option for Carrying RPL 528 Information in Data-Plane Datagrams", RFC 6553, March 529 2012. 531 8.2. Informative References 533 [I-D.bormann-6lo-rpl-mesh] 534 Bormann, C., "NHC compression for RPL Packet Information", 535 draft-bormann-6lo-rpl-mesh-02 (work in progress), October 536 2014. 538 [I-D.ietf-6tisch-architecture] 539 Thubert, P., Watteyne, T., and R. Assimiti, "An 540 Architecture for IPv6 over the TSCH mode of IEEE 541 802.15.4e", draft-ietf-6tisch-architecture-03 (work in 542 progress), July 2014. 544 [I-D.ietf-6tisch-tsch] 545 Watteyne, T., Palattella, M., and L. Grieco, "Using 546 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 547 Statement and Goals", draft-ietf-6tisch-tsch-02 (work in 548 progress), October 2014. 550 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 551 "Transmission of IPv6 Packets over IEEE 802.15.4 552 Networks", RFC 4944, September 2007. 554 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 555 Lossy Networks", RFC 7102, January 2014. 557 Authors' Addresses 559 Pascal Thubert (editor) 560 Cisco Systems 561 Village d'Entreprises Green Side 562 400, Avenue de Roumanille 563 Batiment T3 564 Biot - Sophia Antipolis 06410 565 FRANCE 567 Phone: +33 4 97 23 26 34 568 Email: pthubert@cisco.com 569 Carsten Bormann 570 Universitaet Bremen TZI 571 Postfach 330440 572 Bremen D-28359 573 Germany 575 Phone: +49-421-218-63921 576 Email: cabo@tzi.org