idnits 2.17.1 draft-ietf-lwig-guidance-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1287 has weird spacing: '...Counter lowp...' == Line 1288 has weird spacing: '...Counter lowp...' == Line 1289 has weird spacing: '...Counter ipv6...' -- The document date (August 09, 2012) is 4278 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2873' is mentioned on line 692, but not defined ** Obsolete undefined reference: RFC 2873 (Obsoleted by RFC 9293) == Missing Reference: 'RFC2581' is mentioned on line 703, but not defined ** Obsolete undefined reference: RFC 2581 (Obsoleted by RFC 5681) == Missing Reference: 'Jac88' is mentioned on line 705, but not defined == Missing Reference: 'RFC1323' is mentioned on line 730, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) == Missing Reference: 'RFC3390' is mentioned on line 754, but not defined == Missing Reference: 'RFC3782' is mentioned on line 761, but not defined ** Obsolete undefined reference: RFC 3782 (Obsoleted by RFC 6582) == Missing Reference: 'RFC2018' is mentioned on line 771, but not defined == Missing Reference: 'RFC2883' is mentioned on line 777, but not defined == Missing Reference: 'RFC2923' is mentioned on line 805, but not defined == Missing Reference: '0x02' is mentioned on line 1317, but not defined == Missing Reference: '0x01' is mentioned on line 1317, but not defined == Missing Reference: '0x00' is mentioned on line 1317, but not defined == Missing Reference: 'AVPs' is mentioned on line 1540, but not defined == Missing Reference: 'PRF-Algorithm' is mentioned on line 1488, but not defined == Missing Reference: 'Integrity-Algorithm' is mentioned on line 1488, but not defined == Missing Reference: 'Nonce' is mentioned on line 1547, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 1549, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1553, but not defined == Missing Reference: 'AUTH' is mentioned on line 1553, but not defined == Outdated reference: A later version (-11) exists of draft-clausen-lln-rpl-experiences-04 == Outdated reference: A later version (-12) exists of draft-ietf-6lowpan-btle-09 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-11 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 == Outdated reference: A later version (-01) exists of draft-kivinen-ipsecme-ikev2-minimal-00 == Outdated reference: A later version (-03) exists of draft-mariager-6lowpan-v6over-dect-ule-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) Summary: 4 errors (**), 0 flaws (~~), 29 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group C. Bormann, Ed. 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational August 09, 2012 5 Expires: February 10, 2013 7 Guidance for Light-Weight Implementations of the Internet Protocol Suite 8 draft-ietf-lwig-guidance-02 10 Abstract 12 Implementation of Internet protocols on small devices benefits from 13 light-weight implementation techniques, which are often not 14 documented in an accessible way. 16 This document provides a first outline of and some initial content 17 for the Light-Weight Implementation Guidance document planned by the 18 IETF working group LWIG. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 10, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Call for contributions . . . . . . . . . . . . . . . . . . 6 57 2. Terminology and Scope . . . . . . . . . . . . . . . . . . . . 7 58 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 7 59 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . . 8 60 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 8 61 2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 9 62 2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 9 63 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 10 64 2.4. Scope of this document . . . . . . . . . . . . . . . . . . 10 65 2.5. Terminology boilerplate . . . . . . . . . . . . . . . . . 10 66 3. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Classes of Devices . . . . . . . . . . . . . . . . . . . . 11 68 3.2. Design Objectives . . . . . . . . . . . . . . . . . . . . 11 69 3.3. Implementation Styles . . . . . . . . . . . . . . . . . . 12 70 3.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 13 71 3.5. Overview over the document . . . . . . . . . . . . . . . . 13 72 4. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 14 73 4.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 14 74 4.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 14 75 4.1.1.1. Implementation Considerations for 76 Not-So-Constrained Nodes . . . . . . . . . . . . . 15 77 4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 15 78 4.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 15 79 4.3.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.3.1.1. Absolutely required TCP behaviors for proper 81 functioning and interoperability . . . . . . . . . 16 82 4.3.1.2. Strongly encouraged, but non-essential, 83 behaviors of TCP . . . . . . . . . . . . . . . . . 17 84 4.3.1.3. Experimental extensions that are not yet 85 standard practices . . . . . . . . . . . . . . . . 19 86 4.3.1.4. Others . . . . . . . . . . . . . . . . . . . . . . 19 87 4.4. Application Layer . . . . . . . . . . . . . . . . . . . . 19 88 4.4.1. General considerations about Application 89 Programming Interfaces (APIs) . . . . . . . . . . . . 19 90 4.4.2. Constrained Application Protocol (CoAP) . . . . . . . 20 91 4.4.2.1. Message Layer Processing . . . . . . . . . . . . . 21 92 4.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 22 93 4.4.2.3. Storing Used Message IDs . . . . . . . . . . . . . 23 94 4.4.3. (Other Application Protocols...) . . . . . . . . . . . 26 95 5. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 27 96 5.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 27 97 5.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 27 98 5.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 5.4. Host Configuration and Lookup Services . . . . . . . . . . 27 100 5.5. Network Management . . . . . . . . . . . . . . . . . . . . 27 101 5.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 5.5.1.1. Background . . . . . . . . . . . . . . . . . . . . 28 103 5.5.1.2. Revisiting SNMP implementation for resource 104 constrained devices . . . . . . . . . . . . . . . 28 105 5.5.1.3. Proposed approach for building an memory 106 efficient SNMP agent . . . . . . . . . . . . . . . 29 107 5.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 29 108 5.5.1.5. Further improvements . . . . . . . . . . . . . . . 32 109 5.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . . 32 110 6. Security protocols . . . . . . . . . . . . . . . . . . . . . . 33 111 6.1. Cryptography for Constrained Devices . . . . . . . . . . . 33 112 6.2. Transport Layer Security . . . . . . . . . . . . . . . . . 33 113 6.3. Network Layer Security . . . . . . . . . . . . . . . . . . 33 114 6.4. Network Access Control . . . . . . . . . . . . . . . . . . 33 115 6.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 33 116 6.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 33 117 6.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 34 118 6.4.1.3. PANA session state parameters . . . . . . . . . . 36 119 7. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 39 120 8. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 40 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 123 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 124 11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 43 125 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 126 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 127 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 128 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 130 1. Introduction 132 Today's Internet is experienced by users as a set of applications, 133 such as email, instant messaging, and social networks. There are 134 substantial differences in performance between the various end 135 devices with these applications, but in general end devices 136 participating in the Internet today are considered to have relatively 137 high performance. 139 More and more communications technology is being embedded into our 140 environment. Different types of devices in our buildings, vehicles, 141 equipment and other objects have a need to communicate. It is 142 expected that most of these devices will employ the Internet Protocol 143 suite. The term "Internet of Things" denotes a trend where a large 144 number of devices directly benefit from communication services that 145 use Internet protocols. Many of these devices are not primarily 146 computing devices operated by humans, but exist as components in 147 buildings, vehicles, and the environment. There will be a lot of 148 variation in the computing power, available memory, communications 149 bandwidth, and other capabilities between different types of these 150 devices. With many low-cost, low-power and otherwise constrained 151 devices, it is not always easy to embed all the necessary features. 153 Historically, there has been a trend to invent special "light-weight" 154 _protocols_ to connect the most constrained devices. However, much 155 of this development can simply run on existing Internet protocols, 156 provided some attention is given to achieving light-weight 157 _implementations_. In some cases the new, constrained environments 158 can indeed benefit from protocol optimizations and additional 159 protocols that help optimize Internet communications and lower the 160 computational requirements. Examples of IETF standardization efforts 161 targeted for these environments include the "IPv6 over Low power WPAN 162 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 163 "Constrained RESTful Environments (CoRE)" working groups. More 164 generally, however, techniques are required to implement both these 165 optimized protocols as well as the other protocols of the Internet 166 protocol suite in a way that makes them applicable to a wider range 167 of devices. 169 1.1. Objectives 171 The present document, a product of the IETF Light-Weight 172 Implementation Guidance (LWIG) Working Group, focuses on helping the 173 implementers of the smallest devices. The goal is to be able to 174 build minimal yet interoperable IP-capable devices for the most 175 constrained environments. 177 Building a small implementation does not have to be hard. Many small 178 devices use stripped down versions of general purpose operating 179 systems and their TCP/IP stacks. However, there are implementations 180 that go even further in minimization and can exist in as few as a 181 couple of kilobytes of code, as on some devices this level of 182 optimization is necessary. Technical and cost considerations may 183 limit the computing power, battery capacity, available memory, or 184 communications bandwidth that can be provided. To overcome these 185 limitations the implementers have to employ the right hardware and 186 software mechanisms. For instance, certain types of memory 187 management or even fixed memory allocation may be required. It is 188 also useful to understand what is necessary from the point of view of 189 the communications protocols and the application employing them. For 190 instance, a device that only acts as a client or only requires one 191 connection can simplify its TCP implementation considerably. 193 The purpose of this document is to collect experiences from 194 implementers of IP stacks in constrained devices. The focus is on 195 techniques that have been used in actual implementations and do not 196 impact interoperability with other devices. The techniques shall 197 also not affect conformance to the relevant specifications. We 198 describe implementation techniques for reducing complexity, memory 199 footprint, or power usage. 201 The topics for this working group will be chosen from Internet 202 protocols that are in wide use today, such as IPv4 and IPv6; UDP and 203 TCP; ICMPv4/v6, MLD/IGMP and ND; DNS and DHCPv4/v6; TLS, DTLS and 204 IPsec; as well as from the optimized protocols that result from the 205 work of the 6LoWPAN, RPL, and CoRE working groups. This document 206 will be helpful for the implementers of new devices or for the 207 implementers of new general-purpose small IP stacks. It is also 208 expected that the document will increase our knowledge of what 209 existing small implementations do, and will help in the further 210 optimization of the existing implementations. In areas where the 211 considerations for small implementations have already been documented 212 in an accessible way, we will refer to those documents instead of 213 duplicating the material here. 215 Generic hardware design advice and software implementation techniques 216 are outside the scope of this document. Protocol implementation 217 experience, however, is the focus. There is no intention to describe 218 any new protocols or protocol behavior modifications beyond what is 219 already allowed by existing RFCs, because it is important to ensure 220 that different types of devices can work together. For example, 221 implementation techniques relating to security mechanisms are within 222 scope, but mere removal of security functionality from a protocol is 223 rarely an acceptable approach. 225 1.2. Call for contributions 227 The present draft of the document is an outline that will grow with 228 the contributions received, which are expressly invited. As this 229 document focuses on experience from existing implementations, this 230 requires implementer input; in particular, participation is required 231 from the implementers of existing small IP stacks. "Small" here is 232 intended to be applicable approximately to what is described in 233 Section 3 -- where it is more important that the technique described 234 is grounded in actual experience than that the experience is actually 235 from a (very) constrained system. 237 Only a few subsections are fleshed out in this initial draft; 238 additional subsections will quickly be integrated from additional 239 contributors. 241 2. Terminology and Scope 243 The main focus of the present work appears to be _scaling_: 245 o Scaling up Internet technologies to a large number [50billion] of 246 inexpensive nodes, while 248 o scaling down the characteristics of each of these nodes and of the 249 networks being built out of them, to make this scaling up 250 econmically and physically viable. 252 The need for scaling down the characteristics of nodes leads to 253 _constrained nodes_. 255 2.1. Constrained Nodes 257 The term "constrained node" is best defined on not meeting certain 258 widely held expectations: 260 Constrained Node: A node where some of the characteristics that are 261 otherwise pretty much taken for granted for Internet nodes in 2012 262 are not attainable, often due to cost constraints and/or physical 263 constraints on characteristics such as size, weight, and available 264 power. 266 While this is less than satisfying as a rigorous definition, it is 267 grounded in the state of the art and clearly sets apart constrained 268 nodes from server systems, desktop or laptop computers, powerful 269 mobile devices such as smartphones etc. 271 There are multiple facets to the constraints on nodes, often applying 272 in combination, e.g.: 274 o constraints on the maximum code complexity (ROM/Flash); 276 o constraints on the size of state and buffers (RAM); 278 o constraints on the available power. 280 Section 3.1 defines a small number of interesting classes ("class-N" 281 for N=1,2) of constrained nodes focusing on relevant combinations of 282 the first two constraints. With respect to available power, 283 [RFC6606] distinguishes "power-affluent" nodes (mains-powered or 284 regularly recharged) from "power-constrained nodes" that draw their 285 power from primary batteries or using energy harvesting. 287 The use of constrained nodes in networks often also leads to 288 constraints on the networks themselves. However, there may also be 289 constraints on networks that are largely independent from those of 290 the nodes. We therefore distinguish _constrained networks_ and 291 _constrained node networks_. 293 2.2. Constrained Networks 295 We define "constrained network" in a similar way: 297 Constrained Network: A network where some of the characteristics 298 pretty much taken for granted for Internet link layers in 2012 are 299 not attainable. 301 Again, there may be several reasons for this: 303 o cost constraints on the network 305 o constraints of the nodes (for constrained node networks) 307 o physical constraints (e.g., power constraints, media constraints 308 such as underwater operation, limited spectrum for very high 309 density). 311 Constraints may include: 313 o low achievable bit rate 315 o high packet loss, packet loss (delivery rate) variability 317 o severe penalties for using larger packets (e.g., high packet loss 318 due to link layer fragmentation) 320 o lack of (or severe constraints on) advanced services such as IP 321 multicast 323 2.2.1. Challenged Networks 325 A constrained network is not necessarily a _challenged_ network 326 [FALL]: 328 Challenged Network: A network that has serious trouble maintaining 329 what an applicaton would today expect of the end-to-end IP model, 330 e.g., by: 332 o not being able to offer end-to-end IP connectivity at all; 334 o exhibiting serious interruptions in end-to-end IP connectivity; 335 o exhibiting delay well beyond the MSL defined by TCP. 337 All challenged networks are constrained networks in some sense, but 338 not all constrained networks are challenged networks. There is no 339 well-defined boundary between the two, though. Delay-Tolerant 340 Networking (DTN) has been designed to cope with challenged networks 341 [RFC4838]. 343 2.3. Constrained Node Networks 345 Constrained Node Network: A network whose characteristics are 346 influenced by being composed of a significant portion of 347 constrained nodes. 349 A constrained node network always is a constrained network because of 350 the network constraints stemming from the node constraints, but may 351 also have other constraints that already make it a constrained 352 network. 354 2.3.1. LLN ("low-power lossy network") 356 A related term that has been used recently is "low-power lossy 357 network" (LLN). The ROLL working group currently is struggling with 358 its definition [I-D.ietf-roll-terminology]: 360 LLN: Low power and Lossy networks (LLNs) are typically composed of 361 many embedded devices with limited power, memory, and processing 362 resources interconnected by a variety of links, such as IEEE 363 802.15.4 or Low Power WiFi. There is a wide scope of application 364 areas for LLNs, including industrial monitoring, building 365 automation (HVAC, lighting, access control, fire), connected home, 366 healthcare, environmental monitoring, urban sensor networks, 367 energy management, assets tracking and refrigeration.. [sic] 369 It is not clear that "LLN" is much more specific than "interesting" 370 or "the network characteristics that RPL has been designed for". 371 LLNs do appear to have significant loss at the physical layer, with 372 significant variability of the delivery rate, and some short-term 373 unreliability, coupled with some medium term stability that makes it 374 worthwhile to construct medium-term stable directed acyclic graphs 375 for routing and do measurements on the edges such as ETX. Actual 376 "low power" does not seem to be required for an LLN 377 [I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling 378 of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences]. 380 Also, LLNs seem to be composed of constrained nodes; otherwise 381 operation modes such as RPL's "non-storing mode" would not be 382 sensible. So an LLN seems to be a constrained node network with 383 certain constraints on the network as well. 385 2.3.2. LoWPAN, 6LoWPAN 387 One interesting class of a constrained network often used as a 388 constrained node network is the "LoWPAN" [RFC4919], a term inspired 389 from the name of the IEEE 802.15.4 working group (low-rate wireless 390 personal area networks (LR-WPANs)). The expansion of that acronym, 391 "Low-Power Wireless Personal Area Network" contains a hard to justify 392 "Personal" that is due to IEEE politics more than due to an 393 orientation of LoWPANs around a single person. Actually, LoWPANs 394 have been suggested for urban monitoring, control of large buildings, 395 and industrial control applications, so the "Personal" can only be 396 considered a vestige. Maybe the term is best read as "Low-Power 397 Wireless Area Networks" (LoWPANs) [WEI]. Originally focused on IEEE 398 802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also 399 being used for networks built from similarly constrained link layer 400 technologies [I-D.ietf-6lowpan-btle] 401 [I-D.mariager-6lowpan-v6over-dect-ule]. 403 2.4. Scope of this document 405 Using the above terminology, we can now more precisely define the 406 scope of the present document: 408 This document is about implementation techniques that enable 409 constrained nodes to form constrained node networks. 411 Delay-Tolerant Networks (DTNs) are out of scope. (See Section 1.1 412 above for a further list of non-goals.) 414 2.5. Terminology boilerplate 416 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 417 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 418 document are to be interpreted as described in RFC 2119. As this is 419 an informational document, the [RFC2119] keywords will only be used 420 to underscore requirements where similar key words apply in the 421 context of the specifications the light-weight implementation of 422 which is being discussed. 424 The term "byte" is used in its now customary sense as a synonym for 425 "octet". 427 3. Drawing the Landscape 429 There is not a single kind of constrained, Internet-connected device. 430 To the contrary, the trend is towards much more functional variety of 431 such devices than is customary today in the Internet. This section 432 introduces a number of terms that will be used to locate some of the 433 technique described in the following sections within certain areas of 434 applications. 436 3.1. Classes of Devices 438 Despite the overwhelming variety of Internet-connected devices that 439 can be envisioned, it may, be worthwhile to have some succinct 440 terminology for different classes of constrained devices. In this 441 document, the following class designations may be used as rough 442 indications of device capabilities: 444 +---------+-----------------------+-------------------------+ 445 | Name | data size (e.g., RAM) | code size (e.g., Flash) | 446 +---------+-----------------------+-------------------------+ 447 | Class 1 | ~ 10 KiB | ~ 100 KiB | 448 | | | | 449 | Class 2 | ~ 50 KiB | ~ 250 KiB | 450 +---------+-----------------------+-------------------------+ 452 As of the writing of this document, these characteristics correspond 453 to distinguishable sets of commercially available chips and design 454 cores for constrained devices. While it is expected that the 455 boundaries of these classes will move over time, Moore's law tends to 456 be less effective in the embedded space than in personal computing 457 devices: Gains made available by increases in transistor count and 458 density are more likely to be invested in reductions of cost and 459 power requirements than into continual increases in computing power. 461 3.2. Design Objectives 463 o Consideration for design or implementation approaches for 464 implementation of IP stacks for constrained devices will be 465 impacted by the RAM usage for these designs. Here the 466 consideration is what is the best approach to minimize overhead. 468 o In addition, the impact on throughput in terms of IP protocol 469 implementation must take into consideration the methods that 470 minimize overhead but balance performance requirements for the 471 light-weight constrained devices. 473 o Protocol implementation must consider its impact on CPU 474 utilization. Here guidance will be provided on how to minimize 475 tasks that require additional CPU execution time. 477 How does the implementation of the IP stack effect the application 478 both in terms of performance but also of those same attributes and 479 requirements (RAM, CPU usage, etc.) that we are examining for the IP 480 protocol stack? 482 From performing a synthesis of implementation experiences we will be 483 able to understand and document the benefits and consequences of 484 varied approaches. Scaling code and selected approaches in terms of 485 scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for 486 the approach will aid in the development of single code base when 487 possible. 489 3.3. Implementation Styles 491 Compared to personal computing devices, constrained devices tend to 492 make use of quite different classes of operating systems, if that 493 term is even applicable. 495 ... 497 o Single-threaded/giant mainloop 499 o Event-driven vs. threaded/blocking 501 * The usual multi-threaded model blocks a thread on primitives 502 such as connect(), accept() or read() until an external event 503 takes place. This model is often thought to consume too much 504 RAM and CPU processing. 506 * The event driven model uses a non-blocking approach: E.g., when 507 an application interface sends a message, the routine would 508 return immediately (before the message is sent). A call-back 509 facility notifies the application or calling code when the 510 desired processing is completed. Here the benefit is that no 511 thread context needs to be preserved for long periods of time. 513 o Single/multiple processing elements 515 o E.g., separate radio/network processor 517 Introduce these briefly: Some techniques may be applicable only to 518 some of these styles! 520 3.4. Roles of nodes 522 Constrained nodes are by necessity more specialized than general 523 purpose computing devices; they may have a quite specific role. Some 524 implementation techniques may also 526 o Constrained nodes 528 o Nodes talking to constrained nodes 530 o Gateways/Proxies 532 In all these cases, constrained nodes that are "sleepy" pose 533 additional considerations. (Explain sleepy...) E.g., a node talking 534 to a sleepy node may need to make special arrangements; this is even 535 more true where a gateway or proxy interfaces the general Internet 537 o Bandwidth/latency considerations 539 3.5. Overview over the document 541 The following sections will first go through a number of specific 542 protocol layers, starting from layers of the data plane (link 543 adaptation, network, transport, application), followed by control 544 plane protocol layers (link layer support, network layer and routing, 545 host configuration and lookup services). We then look at security 546 protocols (general cryptography considerations, transport layer 547 security, network layer security, network access control). Finally, 548 we discuss some specific, cross-layer concerns, some "wire-visible", 549 some of concern within a specific implementation. Clearly, many 550 topics could be discussed in more than one place in this structure. 551 The objective is not to have something for each of the potential 552 topics, but to document the most valuable experience that may be 553 available. 555 4. Data Plane Protocols 557 4.1. Link Adaptation Layer 559 6LoWPAN 561 4.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration 563 Author: Carsten Bormann 565 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its 566 minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical 567 layer MTU of only 127 bytes (some of which are taken by MAC layer and 568 adaptation layer headers). Therefore, the adaptation layer provides 569 a fragmentation and reassembly scheme that can fragment a single IPv6 570 packet of up to 1280 bytes into multiple adaptation layer fragments 571 of up to 127 bytes each (including MAC and adaptation layer 572 overhead). 574 In a route-over configuration, implementing this adaptation layer 575 fragmentation scheme straightforwardly means that reassembly and then 576 fragmentation are performed at each forwarding hop. As fragments 577 from several packets may be arriving interleaved with each other, 578 this approach requires buffer space for multiple MTU-size IPv6 579 packets. 581 In a mesh-under configuration, adaptation layer fragments can be 582 forwarded independently of each other. It would be preferable if 583 something similar were possible for route-over. Complete 584 independence in forwarding of adaptation layer fragments is not 585 possible for route-over, however, as the layer-3 addresses needed for 586 forwarding are in the initial bytes of the IPv6 header, which is 587 present only in the first fragment of a larger packet. 589 Instead of performing a full reassembly, implementations may be able 590 to optimize this process by not keeping a full reassembly buffer, but 591 just a runt buffer (called "virtual reassembly buffer" in [WEI]) for 592 each IP packet. This buffer caches only the datagram_tag field (as 593 usual combined with the sender's link layer address, the 594 destination's link layer address and the datagram_size field) and the 595 IPv6 header including the relevant addresses. Initial fragments are 596 then forwarded independently (after header decompression/compression) 597 and create a runt reassembly buffer. Non-initial fragments (which 598 don't require header decompression/compression in 6LoWPAN) are 599 matched against the runt buffers by datagram_tag etc. and forwarded 600 if an IPv6 address is available. (This simple scheme may be 601 complicated a bit if header decompression/compression of the initial 602 fragment causes an overflow of the physical MTU; in this case some 603 overflow data may need to be stored in the runt buffers to be 604 combined with further fragments or may simply be forwarded as a 605 separate additional fragment.) 607 If non-initial fragments arrive out of order before the initial 608 fragment, a route-over router may want to keep the contents of the 609 non-initial fragments until the initial fragment is available, which 610 does need some buffer space. If that is not available, a more 611 constrained route-over router may simply discard out-of order non- 612 initial fragments, possibly taking note that there is no point in 613 forwarding any more fragments with the same combination of 6LoWPAN 614 datagram_tag field, L2 addresses and datagram_size. 616 Runt buffers should time out like full reassembly buffers, and may 617 either keep a map of fragments forwarded or they may simply be 618 removed upon forwarding the final fragment, assuming that no out-of- 619 order fragments will follow. 621 4.1.1.1. Implementation Considerations for Not-So-Constrained Nodes 623 [RFC4944] makes no explicit mandates about the order in which 624 fragments should be sent. Because it is heavily favored by the above 625 implementation techniques, it is highly advisable for all 626 implementations to always send adaptation layer fragments in natural 627 order, i.e., starting with the initial fragment, continuing with 628 increasing datagram_offset. 630 4.2. Network Layer 632 IPv4 and IPv6 634 4.3. Transport Layer 636 TCP and UDP 638 Both TCP and UDP employ 16-bit one's-complement checksums to protect 639 against transmission errors. A number of RFCs discuss efficient 640 implementation techniques for computing and updating Internet 641 Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet 642 Checksum, as opposed to computing it from scratch, may be of interest 643 where a pre-computed packet is provided, e.g., in Flash ROM, and a 644 copy is made in RAM and updated with some current values, or when the 645 actual transmitted packet is composed from pre-defined parts in ROM 646 and new parts in RAM.) 648 4.3.1. TCP 650 Ed. Note: 652 The following outline of a section is an attempt to provide 653 substructure for a future discussion of TCP-related issues based on 654 the TCP Roadmap, [RFC4614]. The indented text, as well as the RFC 655 citations, are copied (and redacted) from there; this certainly needs 656 to be refined in a future version. (Some additional adaptation of 657 the material may also be required as RFC 2581 was since obsoleted by 658 RFC 5681, and RFC 3782 was obsoleted by RFC 6582.) 660 Author: Yuanchen Ma 662 In [RFC4614], the TCP related RFCs are summarized. Some RFCs 663 describe absolutely required TCP behaviors for proper functioning and 664 interoperability. Further RFCs describe strongly encouraged, but 665 non-essential, behaviors. There are also experimental extensions 666 that are not yet standard practices, but that potentially could be in 667 the future. 669 In this subsection, the influence of resource constrained nodes on 670 TCP implementations are summarized according to the lists of 671 [RFC4614]. 673 4.3.1.1. Absolutely required TCP behaviors for proper functioning and 674 interoperability 676 RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) 678 In RFC793, the TCP state machine and event processing, and TCP's 679 semantics for data transmission, reliability, flow control, 680 multiplexing, and acknowledgment. For this part, the constraint of 681 memory will limit the multiplexing capability of TCP. /_text needed 682 for RFC793_/ 684 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 685 (October 1989) 687 RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification 688 (December 1998) 690 RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) 692 This document [RFC2873] removes from the TCP specification all 693 processing of the precedence bits of the TOS byte of the IP 694 header. 696 These three RFCs mandate the support for IPv6 and TOS in IP header, 697 which are a must for resource constrained node to implement. 699 RFC 2581 S: "TCP Congestion Control" (April 1999) 701 Although RFC 793 did not contain any congestion control 702 mechanisms, today congestion control is a required component of 703 TCP implementations. This document [RFC2581] defines the current 704 versions of Van Jacobson's congestion avoidance and control 705 mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. RFC 706 2001 was a conceptual precursor that was obsoleted by RFC 2581. 708 A number of behaviors that together constitute what the community 709 refers to as "Reno TCP" are described in RFC 2581. 711 RFC 1122 mandates the implementation of a congestion control 712 mechanism, and RFC 2581 details the currently accepted mechanism. 713 RFC 2581 differs slightly from the other documents listed in this 714 section, as it does not affect the ability of two TCP endpoints to 715 communicate; however, congestion control remains a critical 716 component of any widely deployed TCP implementation and is 717 required for the avoidance of congestion collapse and to ensure 718 fairness among competing flows. 720 RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) 722 Abstract: "This document defines the standard algorithm that 723 Transmission Control Protocol (TCP) senders are required to use to 724 compute and manage their retransmission timer. 726 4.3.1.2. Strongly encouraged, but non-essential, behaviors of TCP 728 RFC 1323 S: "TCP Extensions for High Performance" (May 1992) 730 This document [RFC1323] defines TCP extensions for window scaling, 731 timestamps, and protection against wrapped sequence numbers, for 732 efficient and safe operation over paths with large bandwidth-delay 733 products. 735 RFC 2675 S: "IPv6 Jumbograms" (August 1999) 737 IPv6 supports longer datagrams than were allowed in IPv4. 739 RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) 740 to IP" (September 2001) 742 4.3.1.2.1. Congestion Control and Loss Recovery Extensions 744 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 745 (January 2001) 747 Abstract: "This document proposes Limited Transmit, a new 748 Transmission Control Protocol (TCP) mechanism that can be used to 749 more effectively recover lost segments when a connection's 750 congestion window is small 752 RFC 3390 S: "Increasing TCP's Initial Window" (October 2002) 754 This document [RFC3390] updates RFC 2581 to permit an initial TCP 755 window of three or four segments during the slow-start phase, 756 depending on the segment size. 758 RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery 759 Algorithm" (April 2004) 761 This document [RFC3782] specifies a modification to the standard 762 Reno fast recovery algorithm, whereby a TCP sender can use partial 763 acknowledgments to make inferences determining the next segment to 764 send in situations where SACK would be helpful but isn't 765 available. 767 4.3.1.2.2. SACK-Based Loss Recovery and Congestion Control 769 RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) 771 This document [RFC2018] defines the basic selective acknowledgment 772 (SACK) mechanism for TCP. 774 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 775 Option for TCP" (July 2000) 777 This document [RFC2883] extends RFC 2018 to cover the case of 778 acknowledging duplicate segments. 780 RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based 781 Loss Recovery Algorithm for TCP" (April 2003) 783 4.3.1.2.3. Dealing with Forged Segments 785 RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996) 787 RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature 788 Option" (August 1998) 790 4.3.1.3. Experimental extensions that are not yet standard practices 792 The experimental extensions are not mature yet. The contents need to 793 be validated to be safe and logical behavior. It is not recommended 794 for the resource constrained node to implement. 796 4.3.1.4. Others 798 RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) 800 From abstract: "This memo catalogs several known Transmission 801 Control Protocol (TCP) implementation problems dealing with Path 802 Maximum Transmission Unit Discovery (PMTUD), including the long- 803 standing black hole problem, stretch acknowlegements (ACKs) due to 804 confusion between Maximum Segment Size (MSS) and segment size, and 805 MSS advertisement based on PMTU." [RFC2923] 807 4.4. Application Layer 809 4.4.1. General considerations about Application Programming Interfaces 810 (APIs) 812 Author: Carl Williams 814 Constrained devices are not necessarily in a position to use APIs 815 that would be considered "standard" for less constrained environments 816 (e.g., Berkeley sockets or those defined by POSIX). 818 When an API implements a protocol, this can be based on proxy methods 819 for remote invocations that underneath rely on the communication 820 protocol. One of the roles of the API can be exactly to hide the 821 detail of the transport protocol. 823 Changes to the lower layers will be made to implement light-weight 824 stacks so this impacts that implementation and inter-workings with 825 the API. Similar considerations such as RAM, CPU utilization and 826 performance requirements apply to the API and its use of the lower 827 layer resources (i.e., buffers). 829 Considerations for the proper approach for a developer to request 830 services from an application program need to be explored and 831 documented. Such considerations will allow the progression of a 832 common consistent networking paradigm without inventing a new way of 833 programming these devices. 835 In addition, such considerations will take into account the inter- 836 working of the API with the protocols. Protocols are more complex to 837 use as they are less direct and take a lot of serializing, de- 838 serializing and dispatching type logic. 840 So the connection of the API and the protocols on a constrained 841 device becomes even more important to balance the requirements of 842 RAM, CPU and performance. 844 _** Here we will proceed to collect and document ... insert 845 experiences from existing API on constrained devices (TBD) **_ 847 4.4.2. Constrained Application Protocol (CoAP) 849 Author: Olaf Bergmann 851 The Constrained Application Protocol [I-D.ietf-core-coap] has been 852 designed specifically for machine-to-machine communication in 853 networks with very constrained nodes. Typical application scenarios 854 therefore include building automation and the Internet of Things. 855 The major design objectives have been set on small protocol overhead, 856 robustness against packet loss, and high latency induced by small 857 bandwidth shares or slow request processing in end nodes. To 858 leverage integration of constrained nodes with the world-wide 859 Internet, the protocol design was led by the architectural style that 860 accounts for the scalability and robustness of the Hypertext Transfer 861 Protocol [RFC2616]. 863 Lightweight implementations benefit from this design in many 864 respects: First, the use of Uniform Resource Identifiers (URIs) for 865 naming resources and the transparent forwarding of their 866 representations in a server-stateless request/response protocol make 867 protocol-translation to HTTP a straightforward task. Second, the set 868 of protocol elements that are inevitable for the core protocol and 869 thus must be implemented on every node has been kept very small to 870 avoid unnecessary accumulation of optional features. Options that -- 871 when present -- are critical for message processing are explicitly 872 marked as such to force immediate rejection of messages with unknown 873 critical options. Third, the syntax of protocol data units is easy 874 to parse and is carefully defined to avoid creation of state in 875 servers where possible. 877 Although these features enable lightweight implementations of the 878 Constrained Application Protocol, there is still a trade-off between 879 robustness and latency of constrained nodes on one hand and resource 880 demands (such as battery consumption, dynamic memory needs and static 881 code-size) on the other. This section gives some guidance on 882 possible strategies to solve this trade-off for very constrained 883 nodes (Class 1 in Section 3.1). The main focus is on servers as this 884 is deemed the predominant case where CoAP applications are faced with 885 tight resource constraints. 887 Additional considerations for the implementation of CoAP on tiny 888 sensors are given in [I-D.arkko-core-sleepy-sensors]. 890 4.4.2.1. Message Layer Processing 892 For constrained nodes of Class 1 or even Class 2, limiting factors 893 for (wireless) network communication usually are RAM size and battery 894 lifetime. Most applications therefore try to avoid dealing with 895 fragmented packets on the network layer and minimize internal buffer 896 space for both transmit and receive operations. One of the most 897 expensive operations hence is the retransmission of messages as it 898 implies additional energy consumption for the (radio) network 899 interface and occupied RAM storage for the send buffer. 901 Where multi-threading is not an option at all because no full-fledged 902 operating system is present, all operations are triggered by a big 903 main loop in a send-receive-dispatch cycle. To implement the packet 904 retransmission, CoAP implementations at least need a separate send 905 buffer and a decent notion of time, e.g. as a strictly monotonic 906 increasing tick counter. For platforms that disable clock tick 907 interrupts in sleep states, the application must take into 908 consideration the clock deviation that occurs during sleep (or ensure 909 to remain in idle state until the message has been acknowledged or 910 the maximum number of retransmissions is reached). Since CoAP allows 911 up to four retransmissions with a binary exponential back-off it 912 could take up to 45 seconds until the send operation is complete. 913 Even in idle state, this means substantial energy consumption for 914 low-power nodes. Implementers therefore might choose a two-step 915 strategy: First, do one or two retransmissions and then, in the later 916 phases of back-off, go to sleep until the next retransmission is due. 917 In the meantime, the node could check for new messages including the 918 acknowledgement for any confirmable message to send. 920 A similar strategy holds for confirmable messages with separate 921 responses. This concept entitles CoAP servers to return an empty 922 acknowledgement to indicate that a confirmable request has been 923 understood and is being processed. Once a proper response has been 924 generate to fulfill the request, it is sent back as a confirmable 925 message as well. The server implementation in this case must be able 926 to map retransmissions of the original request to the ongoing 927 operation and provide the client-selected Token to map between 928 original request and the separate response. 930 Depending on the number of requests that can be handled in parallel, 931 an implementation might create a stub response filled with any option 932 that has to be copied from the original request to the separate 933 response, especially the Token option. The drawback of this 934 technique is that the server must be prepared to receive 935 retransmissions of the previous (confirmable) request to which a new 936 acknowledgement must be generated. If memory is an issue, a single 937 buffer can be used for both tasks: Only the message type and code 938 must be updated, changing the message id is optional. Once the 939 resource representation is known, it is added as new payload at the 940 end of the stub response. Acknowledgements still can be sent as 941 described before as long as no additional options are required to 942 describe the payload. 944 4.4.2.2. Message Parsing 946 Both CoAP clients and servers must construct outgoing CoAP PDUs and 947 parse incoming messages. The basic message header consists of only 948 four octets and thus can be mapped easily to an internal data 949 structure, considering the actual byte order of the host. Once the 950 message is accepted for further processing, the set of options 951 contained in the received message must be decoded to check for 952 unknown critical options. To avoid multiple passes through the 953 option list, the option parser might maintain a bit-vector where each 954 bit represents an option number that is present in the received 955 request. The delta-encoded option number indicates the number of 956 left-shift operations to apply on a bit mask to set the corresponding 957 bit. 959 In addition, the byte index of every option is added to a sparse list 960 (e.g. a one-dimensional array) for fast retrieval. This particularly 961 enables efficient reduced-function handling of options that might 962 occur more than once such as Uri-Path. In this implementation 963 strategy, the delta is zero for any subsequent path segment, hence 964 the stored byte index for option 9 (Uri-Path) will be overwritten to 965 hold a pointer to the last occurrence of that option, i.e., only the 966 last path component actually matters. (Of course, this requires 967 choosing resource names where the combination of (final Uri-Path 968 component, final Uri-Query component) is server-wide unique. 970 Note: Where skipping all but the last path segment is not feasible 971 for some reason, resource identification could be ensured by some 972 hash value calculated over the path segments. For each segment 973 encountered, the stored hash value is updated by the current 974 option value. This works if a cheap _perfect hashing_ scheme can 975 be found for the resource names. 977 Once the option list has been processed at least up to the highest 978 option number that is supported by the application, any known 979 critical option and all elective options can be masked out to 980 determine if any unknown critical option was present. If this is the 981 case, this information can be used to create a 4.02 response 982 accordingly. (Note that the remaining options also must be processed 983 to add further critical options included in the original request.) 985 4.4.2.3. Storing Used Message IDs 987 If CoAP is used directly on top of UDP (i.e., in NoSec mode), it 988 needs to cope with the fact that the UDP datagram transport can 989 reorder and duplicate messages. (In contrast to UDP, DTLS has its 990 own duplicate detection.) CoAP has been designed with protocol 991 functionality such that rejection of duplicate messages is always 992 possible. It is at the discretion of the receiver if it actually 993 wants to make use of this functionality. Processing of duplicate 994 messages comes at a cost, but so does the management of the state 995 associated with duplicate rejection. Hence, a receiver may have good 996 reasons to decide not to do the duplicate rejection. If duplicate 997 rejection is indeed necessary, e.g., for non-idempotent requests, it 998 is important to control the amount of state that needs to be stored. 1000 Author: Esko Dijk 1002 CoAP's duplicate rejection functionality can be straightforwardly 1003 implemented in a CoAP end-point by storing, for each remote CoAP end- 1004 point ("peer") that it communicates with, a list of recently received 1005 CoAP Message IDs (MIDs) along with some timing information. A CoAP 1006 message from a peer with a MID that is in the list for that peer can 1007 simply be discarded. 1009 The timing information in the list can then be used to time out 1010 entries that are older than the _expected extent of the re-ordering_, 1011 an upper bound for which can be estimated by adding the _potential 1012 retransmission window_ ([I-D.ietf-core-coap] section "Reliable 1013 Messages") and the time packets can stay alive in the network. 1015 Such a straightforward implementation is suitable in case other CoAP 1016 end-points generate random MIDs. However, this storage method may 1017 consume substantial RAM in specific cases, such as: 1019 o many clients are making periodic, non-idempotent requests to a 1020 single CoAP server; 1022 o one client makes periodic requests to a large number of CoAP 1023 servers and/or requests a large number of resources; where servers 1024 happen to mostly generate separate CoAP responses (not piggy- 1025 backed); 1027 For example, consider the first case where the expected extent of re- 1028 ordering is 50 seconds, and N clients are sending periodic POST 1029 requests to a single CoAP server during a period of high system 1030 activity, each on average sending one client request per second. The 1031 server would need 100 * N bytes of RAM to store the MIDs only. This 1032 amount of RAM may be significant on a RAM-constrained platform. On a 1033 number of platforms, it may be easier to allocate some extra program 1034 memory (e.g. Flash or ROM) to the CoAP protocol handler process than 1035 to allocate extra RAM. Therefore, one may try to reduce RAM usage of 1036 a CoAP implementation at the cost of some additional program memory 1037 usage and implementation complexity. 1039 Some CoAP clients generate MID values by a using a Message ID 1040 variable [I-D.ietf-core-coap] that is incremented by one each time a 1041 new MID needs to be generated. (After the maximum value 65535 it 1042 wraps back to 0.) We call this behavior "sequential" MIDs. One 1043 approach to reduce RAM use exploits the redundancy in sequential MIDs 1044 for a more efficient MID storage in CoAP servers. 1046 Naturally such an approach requires, in order to actually reduce RAM 1047 usage in an implementation, that a large part of the peers follow the 1048 sequential MID behavior. To realize this optimization, the authors 1049 therefore RECOMMEND that CoAP end-point implementers employ the 1050 "sequential MID" scheme if there are no reasons to prefer another 1051 scheme, such as randomly generated MID values. 1053 Security considerations might call for a choice for 1054 (pseudo)randomized MIDs. Note however that with truly randomly 1055 generated MIDs the probability of MID collision is rather high in use 1056 cases as mentioned before, following from the Birthday Paradox. For 1057 example, in a sequence of 52 randomly drawn 16-bit values the 1058 probability of finding at least two identical values is about 2 1059 percent. 1061 From here on we consider efficient storage implementations for MIDs 1062 in CoAP end-points, that are optimized to store "sequential" MIDs. 1063 Because CoAP messages may be lost or arrive out-of-order, a solution 1064 has to take into account that received MIDs of CoAP messages are not 1065 actually arriving in a sequential fashion, due to lost or reordered 1066 messages. Also a peer might reset and lose its MID counter(s) state. 1067 In addition, a peer may have a single Message ID variable used in 1068 messages to many CoAP end-points it communicates with, which partly 1069 breaks sequentiality from the receiving CoAP end-point's perspective. 1070 Finally, some peers might use a randomly generated MID values 1071 approach. Due to these specific conditions, existing sliding window 1072 bitfield implementations for storing received sequence numbers are 1073 typically not directly suitable for efficiently storing MIDs. 1075 Table 1 shows one example for a per-peer MID storage design: a table 1076 with a bitfield of a defined length _K_ per entry to store received 1077 MIDs (one per bit) that have a value in the range [MID_i + 1 , MID_i 1078 + K]. 1080 +----------+----------------+-----------------+ 1081 | MID base | K-bit bitfield | base time value | 1082 +----------+----------------+-----------------+ 1083 | MID_0 | 010010101001 | t_0 | 1084 | | | | 1085 | MID_1 | 111101110111 | t_1 | 1086 | | | | 1087 | ... etc. | | | 1088 +----------+----------------+-----------------+ 1090 Table 1: A per-peer table for storing MIDs based on MID\\_i 1092 The presence of a table row with base MID_i (regardless of the 1093 bitfield values) indicates that a value MID_i has been received at a 1094 time t_i. Subsequently, each bitfield bit k (0...K-1) in a row i 1095 corresponds to a received MID value of MID_i + k + 1. If a bit k is 1096 0, it means a message with corresponding MID has not yet been 1097 received. A bit 1 indicates such a message has been received already 1098 at approximately time t_i. This storage structure allows e.g. with 1099 k=64 to store in best case up to 130 MID values using 20 bytes, as 1100 opposed to 260 bytes that would be needed for a non-sequential 1101 storage scheme. 1103 The time values t_i are used for removing rows from the table after a 1104 preset timeout period, to keep the MID store small in size and enable 1105 these MIDs to be safely re-used in future communications. (Note that 1106 the table only stores one time value per row, which therefore needs 1107 to be updated on receipt of another MID that is stored as a single 1108 bit in this row. As a consequence of only storing one time value per 1109 row, older MID entries typically time out later than with a simple 1110 per-MID time value storage scheme. The end-point therefore needs to 1111 ensure that this additional delay before MID entries are removed from 1112 the table is much smaller than the time period after which a peer 1113 starts to re-use MID values due to wrap-around of a peer's MID 1114 variable. One solution is to check that a value t_i in a table row 1115 is still recent enough, before using the row and updating the value 1116 t_i to current time. If not recent enough, e.g. older than N 1117 seconds, a new row with an empty bitfield is created.) [Clearly, 1118 these optimizations would benefit if the peer were much more 1119 conservative about re-using MIDs than currently required in the 1120 protocol specification.] 1122 The optimization described is less efficient for storing randomized 1123 MIDs that a CoAP end-point may encounter from certain peers. To 1124 solve this, a storage algorithm may start in a simple MID storage 1125 mode, first assuming that the peer produces non-sequential MIDs. 1126 While storing MIDs, a heuristic is then applied based on monitoring 1127 some "hit rate", for example, the number of MIDs received that have a 1128 Most Significant Byte equal to that of the previous MID divided by 1129 the total number of MIDs received. If the hit rate tends towards 1 1130 over a period of time, the MID store may decide that this particular 1131 CoAP end-point uses sequential MIDs and in response improve 1132 efficiency by switching its mode to the bitfield based storage. 1134 4.4.3. (Other Application Protocols...) 1135 5. Control Plane Protocols 1137 5.1. Link Layer Support 1139 ARP, ND; 6LoWPAN-ND 1141 5.2. Network Layer 1143 ICMP, ICMPv6, IGMP/MLD 1145 5.3. Routing 1147 RPL, AODV/DYMO, OLSRv2 1149 5.4. Host Configuration and Lookup Services 1151 DNS, DHCPv4, DHCPv6 1153 5.5. Network Management 1155 SNMP, netconf? 1157 5.5.1. SNMP 1159 Author: Brinda M C 1161 This section describes an approach for developing a light-weight SNMP 1162 agent for resource constrained devices running the 6LoWPAN/RPL 1163 protocol stack. The motivation for the work is driven by two major 1164 factors: 1166 o SNMP plays a vital role in monitoring and managing any operational 1167 network; 6LoWPAN based WSN is no exception to this. 1169 o There is a need for building a light-weight SNMP agent which 1170 consumes less memory and less computational resources. 1172 The following subsections are organized as follows: 1174 o Section 5.5.1.1 provides some background. 1176 o In Section 5.5.1.2, we revisit existing SNMP implementation in the 1177 context of memory constrained devices. 1179 o In Section 5.5.1.3, we present our approach for building a memory 1180 efficient SNMP agent. 1182 o Using a realistic example, in Section 5.5.1.4, we illustrate how 1183 the proposed method can be implemented. 1185 o In Section 5.5.1.5, we explore a few ideas which can further help 1186 in improving the memory utilization. 1188 5.5.1.1. Background 1190 Our initial SNMP agent implementation was completely based on Net- 1191 SNMP, well-known open-source network monitoring and management 1192 software. After porting the agent on to the TelosB mote, we observed 1193 that it occupies a text program memory of more than 8 KiB on TinyOS 1194 and Contiki OS platforms. (Note that both these platforms already 1195 use compiler optimizations to minimize the memory footprint.) 8 KiB 1196 is already non-negligible given the 48 KiB program memory limit of 1197 TelosB. Added to this, the memory taken up by 6LoWPAN and the 1198 related protocol stacks are ever growing, causing serious memory 1199 crunch in the resource constrained devices. We reached a situation 1200 where we could not build an image on the TinyOS/Contiki OS platforms 1201 with our SNMP agent. 1203 We came across SNMPv1 agent implementations elsewhere in the 1204 literature which also report similar memory consumption. This 1205 motivated us to have a re-look at the existing SNMP agent 1206 implementation, and explore the possibility of an alternate 1207 implementation using altogether a different approach. 1209 5.5.1.2. Revisiting SNMP implementation for resource constrained 1210 devices 1212 If we look at a typical SNMP agent implementation, we can see that 1213 much of the memory consuming code is pertaining to ASN.1 related SNMP 1214 PDU parsing and SNMP PDU build operations. The SNMP parsing mainly 1215 recovers various fields from the incoming PDU, such as the OIDs, 1216 whereas the SNMP PDU build is the reverse operation of building the 1217 response PDU from the OIDs. 1219 The key observation is that, for a given MIB definition, an OID of 1220 interest contained in the incoming SNMP PDU is already available, 1221 albeit in an encoded form. This enables identifying the OID from the 1222 packet in its "raw" form, simplifying parser operation. 1224 We also can make use of this observation while building the response 1225 SNMP PDU. For a given MIB definition, we can think of statically 1226 having a pre-composed ASN.1 encoded version of OIDs, and use them 1227 while constructing the response SNMP PDU. 1229 5.5.1.3. Proposed approach for building an memory efficient SNMP agent 1231 As noted in the previous section, since an SNMP OID is already 1232 _contained_ in the incoming network PDU, we came up with a simple OID 1233 signature identification method performed directly on the network PDU 1234 through simple memory comparisons and table look-ups. Once the OID 1235 has been identified from the packet "in situ", the corresponding per- 1236 OID processing is carried out. Through this scheme we completely 1237 eliminated expensive SNMP parse operations. 1239 For the SNMP PDU build, we use _pre-encoded_ OID variables which can 1240 simply be plugged into the network SNMP response packet directly 1241 depending on the request OID. Now that the expensive build operation 1242 is taken care, what remains is the construction of the overall SNMP 1243 pdu which can be built through simple logic. Through this scheme we 1244 completely eliminated expensive SNMP build operations. 1246 Based on these ideas, we have re-architected our original SNMP agent 1247 implementation and with our new implementation we were able to bring 1248 down its text memory usage all the way down to 4 KiB from the native 1249 SNMP agent implementation which occupied 8 KiB. 1251 5.5.1.3.1. Discussion on memory usage 1253 With respect to the memory usage, while we have achieved major 1254 reduction in terms of text program memory, which occupies a major 1255 chunk of memory, a question might come to mind with regard to the 1256 static memory allocation for maintaining the tables. We found that 1257 this is not very significant to start with. Through an efficient 1258 table representation, we further optimized the memory consumption. 1259 We could do so because a typical OID description is mainly dominated 1260 by a fixed part of the hierarchy. This enables us to define few 1261 static prefixes, each corresponding to a particular hierarchy level 1262 of the OID. In the context of 6LoWPAN, it can be expected that the 1263 number of hierarchy levels will be small. 1265 5.5.1.4. Example 1267 This section illustrates the simplicity and practicality of our 1268 approach with an example. Let us consider the fragment of a 1269 representative MIB definition depicted in Figure 1 1270 iso 1271 | 1272 org 1273 | 1274 dod 1275 | 1276 internet 1277 | 1278 mgmt.mib-2 1279 | 1280 lowpanMIB 1281 | 1282 +--lowpanPrimaryStatistics(10) 1283 | 1284 +--PrimeStatsEntry(1) 1285 | 1286 +-- -R-- INTEGER lowpanMoteBatteryVoltageP(1) 1287 +-- -R-- Counter lowpanFramesReceivedP(2) 1288 +-- -R-- Counter lowpanFramesSentP(3) 1289 +-- -R-- Counter ipv6ForwardedMsgP(4) 1290 +-- -R-- Counter OUTSolicitationP(5) 1291 +-- -R-- Counter OUTAdvertisementP(6) 1293 Figure 1: A fragment of a MIB hierarchy 1295 5.5.1.4.1. Optimized SNMP Parsing 1297 Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP 1298 and lowpanFramesSentP. Corresponding to these OIDs, a C array dump 1299 of the network PDU of SNMP packet with two OIDs in a variable binding 1300 would look as in Figure 2. 1302 char snmp_get_req_pkt[] = { 1303 0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06, 1304 0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30, 1305 0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01, 1306 0x00, 0x02, 0x01, 0x00, 0x30, 0x22, 0x30, 0x0f, 1307 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1308 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00, 0x30, 1309 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 1310 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00 }; 1312 Figure 2: An SNMP packet, represented in C 1314 Inspecting the above packet, we see that the main components of the 1315 PDU are: 1317 1. Version (SNMPv1): [0x02, 0x01, 0x00] 1319 2. Community Name ("public"): [0x04, 0x06, 0x70, 0x75, 0x62, 0x6c, 1320 0x69, 0x63] 1322 3. ASN.1 encoded OIDs for lowpanMoteBatteryVoltageP, and 1323 lowpanFramesReceivedP: 1325 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1326 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00] 1328 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1329 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00] 1331 There is a significant overlap between the two OIDs, which can be 1332 used to simplify the parsing process. We can, for instance, define 1333 one statically initialized array containing elements common between 1334 these OIDs. Using this notion of common prefix idea, we can come up 1335 with an optimized table and the OID identification then boils down to 1336 simple memory comparisons within this table. The optimized table 1337 construction will also result in scalability. 1339 5.5.1.4.2. Optimized SNMP Build 1341 Extending the same approach as described above, we can build the GET 1342 response by plugging in pre-encoded OIDs into the response packets. 1343 So, corresponding to the GET request for the OIDs as given in section 1344 4.1, we can define C arrays containing pre-encoded OIDs which can go 1345 into the response packet as in Figure 3. 1347 pdu_batt_volt[] = { 1348 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1349 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02, 1350 0x02, 0x00, 0x00 }; 1352 pdu_frames_sent[] = { 1353 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1354 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x41, 1355 0x02, 0x00, 0x00 }; 1357 Figure 3: Pre-encoded OIDs 1359 Since the ASN.1 basic encoding rules are in TLV format, the offset 1360 within the encoded OID where the value needs to be filled-in can be 1361 obtained from the length field. 1363 The table size optimization discussed in the previous section can be 1364 applied here, too. 1366 Note: Though we have taken a simple example to illustrate the 1367 efficacy of the proposed approach, the ideas presented here can 1368 easily be extended to other scenarios as well. 1370 5.5.1.5. Further improvements 1372 A few simple methods can reduce the code size as well as generate 1373 computationally inexpensive code. These methods might sound obvious 1374 and trivial but are important for constrained devices. 1376 o If possible, avoid using memory consuming data types such as 1377 floating point while representing a monitored variable when an 1378 equivalent representation of the same that occupies less memory is 1379 adequate. For example, while a battery voltage indication could 1380 take a fractional value between 0 and 3 V, opt for an 8-bit 1381 quantized value. 1383 o Using meta data in the MIB definition instead of absolute numbers 1384 can bring down the memory and processing significantly and can 1385 improve scalability too especially for a large scale WSN 1386 deployments. Using the same example of battery voltage, one might 1387 think of an OID which represents fewer levels of the battery 1388 voltage signifying high, medium, low, very low. 1390 o While a multi-level hierarchy for MIB definition might improve OID 1391 segregation the flip side is that it increases the overall length 1392 of the OID and results in extra memory and processing overhead. 1393 One may have to make a judicious choice while coming up with the 1394 MIB. 1396 5.5.1.6. Conclusion 1398 This subsection proposes a simple SNMP packet processing based 1399 approach for building a light-weight SNMP agent. While there is 1400 scope for further improvement, we believe that the proposed method 1401 can be a reasonably good starting point for resource constrained 1402 6LoWPAN based networks. 1404 6. Security protocols 1406 6.1. Cryptography for Constrained Devices 1408 6.2. Transport Layer Security 1410 TLS, DTLS, ciphersuites, certificates 1412 6.3. Network Layer Security 1414 IPsec, IKEv2, transforms 1416 Advice for a minimal implementation of IKEv2 can be found in 1417 [I-D.kivinen-ipsecme-ikev2-minimal]. 1419 6.4. Network Access Control 1421 (PANA, EAP, EAP methods) 1423 6.4.1. PANA 1425 Author: Mitsuru Kanda 1427 PANA [RFC5191] provides network access authentication between clients 1428 and access networks. The PANA protocol runs between a PANA Client 1429 (PaC) and a PANA Authentication Agent (PAA). PANA carries UDP 1430 encapsulated EAP [RFC3748] and includes various operational options. 1431 From the point of view of minimal implementation, some of these are 1432 not necessary for constrained devices. This section describes a 1433 minimal PANA implementation for these devices. 1435 The minimization objective for this implementation mainly targets 1436 PaCs because constrained devices often are installed as network 1437 clients, such as sensors, metering devices, etc. 1439 6.4.1.1. PANA AVPs 1441 Each PANA message can carry zero or more AVPs (Attribute-Value Pairs) 1442 within its payload. [RFC5191] specifies nine types of AVPs (AUTH, 1443 EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm, 1444 Result-Code, Session-Lifetime, and Termination-Cause). All of them 1445 are required by all minimal implementations. But there are some 1446 notes. 1448 Integrity-Algorithm AVP and PRF-Algorithm AVP: 1450 All PANA implementations MUST support AUTH_HMAC_SHA1_160 for PANA 1451 message integrity protection and PRF_HMAC_SHA1 for pseudo-random 1452 function (PRF) specified in [RFC5191]. Both of these are based on 1453 SHA-1, which therefore needs to be implemented in a minimal 1454 implementation. 1456 Nonce AVP: 1458 As the basic hash function is SHA-1, including a nonce of 20 bytes in 1459 the Nonce AVP is appropriate ([RFC5191], section 8.5). 1461 6.4.1.2. PANA Phases 1463 A PANA session consists of four phases -- Authentication and 1464 authorization phase, Access phase, Re-Authentication phase, and 1465 Termination phase. 1467 Authentication and authorization phase: 1469 There are two types of PANA session initiation, PaC-initiated session 1470 and PAA-initiated session. The minimal implementation must support 1471 PaC-initiated session and does not need to support PAA-initiated 1472 session. Because a PaC (a constrained device) which may be a 1473 sleeping device, can not receive an unsolicited PANA-Auth-Request 1474 message from a PAA (PAA-initiated session). 1476 EAP messages can be carried in PANA-Auth-Request and PANA-Auth-Answer 1477 messages. In order to reduce the number of messages, "Piggybacking 1478 EAP" is useful. Both the PaC and PAA should include EAP-Payload AVP 1479 in each of PANA-Auth-Request and PANA-Auth-Answer messages as much as 1480 possible. Figure 4 shows an example "Piggybacking EAP" sequence of 1481 the Authentication and authorization phase. 1483 PaC PAA Message(sequence number)[AVPs] 1484 --------------------------------------------------------------------- 1485 -----> PANA-Client-Initiation(0) 1486 <----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm] 1487 // The 'S' (Start) bit set 1488 -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm] 1489 // The 'S' (Start) bit set 1490 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 1491 -----> PANA-Auth-Answer(x+1)[Nonce, EAP-Payload] 1492 <----- PANA-Auth-Request(x+2)[EAP-Payload] 1493 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 1494 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 1495 Key-Id, Session-Lifetime, AUTH] 1496 // The 'C' (Complete) bit set 1497 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 1498 // The 'C' (Complete) bit set 1500 Figure 4: Example sequence of the Authentication and authorization 1501 phase for a PaC-initiated session (using "Piggybacking EAP") 1503 Note: It is possible to include an EAP-Payload in both the PANA-Auth- 1504 Request and PANA-Auth-Answer messages with the 'S' bit set. But the 1505 PAA should not include an EAP-Payload in the PANA-Auth-Request 1506 message with the 'S' bit set in order to stay stateless in response 1507 to a PANA-Client-Initiation message. 1509 Access phase: 1511 After Authentication and authorization phase completion, the PaC and 1512 PAA share a PANA Security Association (SA) and move Access phase. 1513 During Access phase, [RFC5191] describes both the PaC and PAA can 1514 send a PANA-Notification-Request message with the 'P' (Ping) bit set 1515 for the peer's PANA session liveness check (a.k.a "PANA ping"). From 1516 the minimal implementation point of view, the PAA should not send a 1517 PANA-Notification-Request message with the 'P' (Ping) bit set to 1518 initiate PANA ping since the PaC may be sleeping. The PaC does not 1519 need to send a PANA-Notification-Request message with the 'P' (Ping) 1520 bit set for PANA ping to the PAA periodically and may omit the PANA 1521 ping feature itself if the PaC can detect the PANA session failure by 1522 other methods, for example, network communication failure. In 1523 conclusion, the PaC does not need to implement the periodic liveness 1524 check feature sending PANA ping but a PaC that is awake should 1525 respond to a incoming PANA-Notification-Request message with the 'P' 1526 (Ping) bit set for PANA ping as possible. 1528 Re-Authentication phase: 1530 Before PANA session lifetime expiration, the PaC and PAA MUST re- 1531 negotiate to keep the PANA session. This means that the PaC and PAA 1532 enter Re-Authentication phase. Also in the Authentication and 1533 authorization phase, there are two types of re-authentication. The 1534 minimal implementation must support PaC-initiated re-authentication 1535 and does not need to support PAA-initiated re-authentication (again 1536 because the PaC may be a sleeping device). "Piggybacking EAP" is 1537 also useful here and should be used as well. Figure 5 shows an 1538 example "Piggybacking EAP" sequence of the Re-Authentication phase. 1540 PaC PAA Message(sequence number)[AVPs] 1541 --------------------------------------------------------------------- 1542 -----> PANA-Notification-Request(q)[AUTH] 1543 // The 'A' (re-Authentication) bit set 1544 <----- PANA-Notification-Answer(q)[AUTH] 1545 // The 'A' (re-Authentication) bit set 1546 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 1547 -----> PANA-Auth-Answer(p)[EAP-Payload, Nonce, AUTH] 1548 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 1549 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 1550 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 1551 Key-Id, Session-Lifetime, AUTH] 1552 // The 'C' (Complete) bit set 1553 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] 1554 // The 'C' (Complete) bit set 1556 Figure 5: Example sequence of the Re-Authentication phase for a PaC- 1557 initiated session (using "Piggybacking EAP") 1559 Termination Phase: 1561 The PaC and PAA should not send a PANA-Termination-Request message 1562 except for explicitly terminating a PANA session within the lifetime. 1563 Both the PaC and PAA know their own PANA session lifetime expiration. 1564 This means the PaC and PAA should not send a PANA-Termination-Request 1565 message when the PANA session lifetime expired because of reducing 1566 message processing cost. 1568 6.4.1.3. PANA session state parameters 1570 All PANA implementations internally keep PANA session state 1571 information for each peer. At least, all minimal implementations 1572 need to keep PANA session state parameters below (in the second 1573 column storage sizes are given in bytes): 1575 +------------------+----------+-------------------------------------+ 1576 | State Parameter | Size | Comment | 1577 +------------------+----------+-------------------------------------+ 1578 | PANA Phase | 1 | Used for recording the current PANA | 1579 | Information | | phase. | 1580 | | | | 1581 | PANA Session | 4 | | 1582 | Identifier | | | 1583 | | | | 1584 | PaC's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | 1585 | and UDP port | | and 16 bytes for IPv6) plus 2 bytes | 1586 | number | | for UDP port number. | 1587 | | | | 1588 | PAA's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | 1589 | and UDP port | | and 16 bytes for IPv6) plus 2 bytes | 1590 | number | | for UDP port number. | 1591 | | | | 1592 | Outgoing message | 4 | Next outgoing request message | 1593 | sequence number | | sequence number. | 1594 | | | | 1595 | Incoming message | 4 | Next expected incoming request | 1596 | sequence number | | message sequence number. | 1597 | | | | 1598 | A copy of the | variable | Necessary to be able to retransmit | 1599 | last sent | | the message (unless it can be | 1600 | message payload | | reconstructed on the fly). | 1601 | | | | 1602 | Retransmission | 4 | | 1603 | interval | | | 1604 | | | | 1605 | PANA Session | 4 | | 1606 | lifetime | | | 1607 | | | | 1608 | PaC nonce | 20 | Generated by PaC and carried in the | 1609 | | | Nonce AVP. | 1610 | | | | 1611 | PAA nonce | 20 | Generated by PAA and carried in the | 1612 | | | Nonce AVP. | 1613 | | | | 1614 | EAP MSK | 4 | | 1615 | Identifier | | | 1616 | | | | 1617 | EAP MSK value | *) | Generated by EAP method and used | 1618 | | | for generating PANA_AUTH_KEY. | 1619 | | | | 1620 | PANA_AUTH_KEY | 20 | Necessary for PANA message | 1621 | | | protection. | 1622 | | | | 1623 | PANA PRF | 4 | Used for generating PANA_AUTH_KEY. | 1624 | algorithm number | | | 1625 | | | | 1626 | PANA Integrity | 4 | Necessary for PANA message | 1627 | algorithm number | | protection. | 1628 +------------------+----------+-------------------------------------+ 1630 *) (Storage size depends on the key derivation algorithm.) 1632 Note: EAP parameters except for MSK have not been listed here. These 1633 EAP parameters are not used by PANA and depend on what EAP method you 1634 choose. 1636 7. Wire-Visible Constraints 1638 o Checksum 1640 o MTU 1642 o Fragmentation and reassembly 1644 o Options -- implications of leaving some out 1646 o Simplified TCP optimized for LLNs 1648 o Out-of-order packets 1650 8. Wire-Invisible Constraints 1652 o Buffering 1654 o Memory management 1656 o Timers 1658 o Energy efficiency 1660 o API 1662 o Data structures 1664 o Table sizes (somewhat wire-visible) 1666 o Improved error handling due to resource overconsumption 1668 9. IANA Considerations 1670 This document makes no requirements on IANA. (This section to be 1671 removed by RFC editor.) 1673 10. Security Considerations 1675 (TBD.) 1677 11. Acknowledgements 1679 Much of the text of the introduction is taken from the charter of the 1680 LWIG working group and the invitation to the IAB workshop on 1681 Interconnecting Smart Objects with the Internet. Thanks to the 1682 numerous contributors. Angelo Castellani provided comments that led 1683 to improved text. 1685 11.1. Contributors 1687 The RFC guidelines no longer allow RFCs to be published with a large 1688 number of authors. As there are many authors that have contributed 1689 to the sections of this document, their names are listed in the 1690 individual section headings as well as alphabetically listed with 1691 their affiliations below. 1693 +-------------+-----------------------+-----------------------------+ 1694 | Name | Affiliation | Contact | 1695 +-------------+-----------------------+-----------------------------+ 1696 | Brinda M C | Indian Institute of | brinda@ece.iisc.ernet.in | 1697 | | Science | | 1698 | | | | 1699 | Carl | MCSR Labs | carlw@mcsr-labs.org | 1700 | Williams | | | 1701 | | | | 1702 | Carsten | Universitaet Bremen | cabo@tzi.org | 1703 | Bormann | TZI | | 1704 | | | | 1705 | Esko Dijk | Philips Research | esko.dijk@philips.com | 1706 | | | | 1707 | Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp | 1708 | Kanda | | | 1709 | | | | 1710 | Olaf | Universitaet Bremen | bergmann@tzi.org | 1711 | Bergmann | TZI | | 1712 | | | | 1713 | Yuanchen Ma | Hitachi (China) R&D | ycma@hitachi.cn | 1714 | | Corporation | | 1715 | | | | 1716 | ... | ... | | 1717 +-------------+-----------------------+-----------------------------+ 1719 12. References 1721 12.1. Normative References 1723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1724 Requirement Levels", BCP 14, RFC 2119, March 1997. 1726 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1727 "Transmission of IPv6 Packets over IEEE 802.15.4 1728 Networks", RFC 4944, September 2007. 1730 12.2. Informative References 1732 [50billion] 1733 "More Than 50 Billion Connected Devices", ericsson white 1734 paper 284 23-3149 Uen, February 2011, . 1737 [FALL] Fall, K., "A Delay-Tolerant Network Architecture for 1738 Challenged Internets", SIGCOMM 2003. 1740 [I-D.arkko-core-sleepy-sensors] 1741 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 1742 Novo, "Implementing Tiny COAP Sensors", 1743 draft-arkko-core-sleepy-sensors-01 (work in progress), 1744 July 2011. 1746 [I-D.clausen-lln-rpl-experiences] 1747 Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. 1748 Igarashi, "Observations of RPL: IPv6 Routing Protocol for 1749 Low power and Lossy Networks", 1750 draft-clausen-lln-rpl-experiences-04 (work in progress), 1751 July 2012. 1753 [I-D.hui-vasseur-roll-rpl-deployment] 1754 Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL 1755 deployment experience in large scale networks", 1756 draft-hui-vasseur-roll-rpl-deployment-01 (work in 1757 progress), July 2012. 1759 [I-D.ietf-6lowpan-btle] 1760 Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., 1761 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 1762 over Bluetooth Low Energy", draft-ietf-6lowpan-btle-09 1763 (work in progress), July 2012. 1765 [I-D.ietf-core-coap] 1766 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1767 "Constrained Application Protocol (CoAP)", 1768 draft-ietf-core-coap-11 (work in progress), July 2012. 1770 [I-D.ietf-roll-terminology] 1771 Vasseur, J., "Terminology in Low power And Lossy 1772 Networks", draft-ietf-roll-terminology-06 (work in 1773 progress), September 2011. 1775 [I-D.kivinen-ipsecme-ikev2-minimal] 1776 Kivinen, T., "Minimal IKEv2", 1777 draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), 1778 February 2011. 1780 [I-D.mariager-6lowpan-v6over-dect-ule] 1781 Mariager, P. and J. Petersen, "Transmission of IPv6 1782 Packets over DECT Ultra Low Energy", 1783 draft-mariager-6lowpan-v6over-dect-ule-02 (work in 1784 progress), May 2012. 1786 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1787 "Computing the Internet checksum", RFC 1071, 1788 September 1988. 1790 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 1791 Internet checksum", RFC 1141, January 1990. 1793 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1794 Incremental Update", RFC 1624, May 1994. 1796 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1797 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1798 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1800 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1801 Levkowetz, "Extensible Authentication Protocol (EAP)", 1802 RFC 3748, June 2004. 1804 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1805 for Transmission Control Protocol (TCP) Specification 1806 Documents", RFC 4614, September 2006. 1808 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1809 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1810 Networking Architecture", RFC 4838, April 2007. 1812 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1813 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1814 Overview, Assumptions, Problem Statement, and Goals", 1815 RFC 4919, August 2007. 1817 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1818 Yegin, "Protocol for Carrying Authentication for Network 1819 Access (PANA)", RFC 5191, May 2008. 1821 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1822 Statement and Requirements for IPv6 over Low-Power 1823 Wireless Personal Area Network (6LoWPAN) Routing", 1824 RFC 6606, May 2012. 1826 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1827 Internet", ISBN 9780470747995, 2009. 1829 Author's Address 1831 Carsten Bormann (editor) 1832 Universitaet Bremen TZI 1833 Postfach 330440 1834 Bremen D-28359 1835 Germany 1837 Phone: +49-421-218-63921 1838 Email: cabo@tzi.org