idnits 2.17.1 draft-ietf-lwig-guidance-03.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 1102 has weird spacing: '...Counter lowp...' == Line 1103 has weird spacing: '...Counter lowp...' == Line 1104 has weird spacing: '...Counter ipv6...' -- The document date (February 25, 2013) is 4070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2873' is mentioned on line 506, but not defined ** Obsolete undefined reference: RFC 2873 (Obsoleted by RFC 9293) == Missing Reference: 'RFC2581' is mentioned on line 517, but not defined ** Obsolete undefined reference: RFC 2581 (Obsoleted by RFC 5681) == Missing Reference: 'Jac88' is mentioned on line 519, but not defined == Missing Reference: 'RFC1323' is mentioned on line 544, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) == Missing Reference: 'RFC3390' is mentioned on line 568, but not defined == Missing Reference: 'RFC3782' is mentioned on line 575, but not defined ** Obsolete undefined reference: RFC 3782 (Obsoleted by RFC 6582) == Missing Reference: 'RFC2018' is mentioned on line 585, but not defined == Missing Reference: 'RFC2883' is mentioned on line 591, but not defined == Missing Reference: 'RFC2923' is mentioned on line 619, but not defined == Missing Reference: '0x02' is mentioned on line 1132, but not defined == Missing Reference: '0x01' is mentioned on line 1132, but not defined == Missing Reference: '0x00' is mentioned on line 1132, but not defined == Missing Reference: 'AVPs' is mentioned on line 1356, but not defined == Missing Reference: 'PRF-Algorithm' is mentioned on line 1304, but not defined == Missing Reference: 'Integrity-Algorithm' is mentioned on line 1304, but not defined == Missing Reference: 'Nonce' is mentioned on line 1363, but not defined == Missing Reference: 'EAP-Payload' is mentioned on line 1365, but not defined == Missing Reference: 'Key-Id' is mentioned on line 1369, but not defined == Missing Reference: 'AUTH' is mentioned on line 1369, but not defined == Unused Reference: 'I-D.ietf-6lowpan-btle' is defined on line 1562, but no explicit reference was found in the text == Unused Reference: 'I-D.mariager-6lowpan-v6over-dect-ule' is defined on line 1577, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == 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 (~~), 28 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 February 25, 2013 5 Expires: August 29, 2013 7 Guidance for Light-Weight Implementations of the Internet Protocol Suite 8 draft-ietf-lwig-guidance-03 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 August 29, 2013. 37 Copyright Notice 39 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Call for contributions . . . . . . . . . . . . . . . . . 5 57 1.3. Terminology used in this document . . . . . . . . . . . . 5 58 1.4. Scope of the present document . . . . . . . . . . . . . . 6 59 1.5. Terminology boilerplate . . . . . . . . . . . . . . . . . 6 60 2. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Design Objectives . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Implementation Styles . . . . . . . . . . . . . . . . . . 7 63 2.3. Roles of nodes . . . . . . . . . . . . . . . . . . . . . 8 64 2.4. Overview over the document . . . . . . . . . . . . . . . 8 65 3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 8 67 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 8 68 3.1.1.1. Implementation Considerations for Not-So- 69 Constrained Nodes . . . . . . . . . . . . . . . . 10 70 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 72 3.3.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.3.1.1. Absolutely required TCP behaviors for proper 74 functioning and interoperability . . . . . . . . 11 75 3.3.1.2. Strongly encouraged, but non-essential, behaviors 76 of TCP . . . . . . . . . . . . . . . . . . . . . 12 77 3.3.1.3. Experimental extensions that are not yet standard 78 practices . . . . . . . . . . . . . . . . . . . . 13 79 3.3.1.4. Others . . . . . . . . . . . . . . . . . . . . . 13 80 3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 14 81 3.4.1. General considerations about Application Programming 82 Interfaces (APIs) . . . . . . . . . . . . . . . . . . 14 83 3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 14 84 3.4.2.1. Message Layer Processing . . . . . . . . . . . . 15 85 3.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 16 86 3.4.2.3. Storing Used Message IDs . . . . . . . . . . . . 17 87 3.4.3. (Other Application Protocols...) . . . . . . . . . . 20 88 4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 20 89 4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . 20 90 4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 20 91 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 4.4. Host Configuration and Lookup Services . . . . . . . . . 21 93 4.5. Network Management . . . . . . . . . . . . . . . . . . . 21 94 4.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . 21 95 4.5.1.1. Background . . . . . . . . . . . . . . . . . . . 21 96 4.5.1.2. Revisiting SNMP implementation for resource 97 constrained devices . . . . . . . . . . . . . . . 22 98 4.5.1.3. Proposed approach for building an memory 99 efficient SNMP agent . . . . . . . . . . . . . . 22 100 4.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 23 101 4.5.1.5. Further improvements . . . . . . . . . . . . . . 25 102 4.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . 26 103 5. Security protocols . . . . . . . . . . . . . . . . . . . . . 26 104 5.1. Cryptography for Constrained Devices . . . . . . . . . . 26 105 5.2. Transport Layer Security . . . . . . . . . . . . . . . . 26 106 5.3. Network Layer Security . . . . . . . . . . . . . . . . . 26 107 5.4. Network Access Control . . . . . . . . . . . . . . . . . 26 108 5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . 26 109 5.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 27 110 5.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 27 111 5.4.1.3. PANA session state parameters . . . . . . . . . . 29 112 6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . 31 113 7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . 31 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 117 10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 32 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 120 11.2. Informative References . . . . . . . . . . . . . . . . . 33 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 123 1. Introduction 125 Today's Internet is experienced by users as a set of applications, 126 such as email, instant messaging, and social networks. There are 127 substantial differences in performance between the various end 128 devices with these applications, but in general end devices 129 participating in the Internet today are considered to have relatively 130 high performance. 132 More and more communications technology is being embedded into our 133 environment. Different types of devices in our buildings, vehicles, 134 equipment and other objects have a need to communicate. It is 135 expected that most of these devices will employ the Internet Protocol 136 suite. The term "Internet of Things" denotes a trend where a large 137 number of devices directly benefit from communication services that 138 use Internet protocols. Many of these devices are not primarily 139 computing devices operated by humans, but exist as components in 140 buildings, vehicles, and the environment. There will be a lot of 141 variation in the computing power, available memory, communications 142 bandwidth, and other capabilities between different types of these 143 devices. With many low-cost, low-power and otherwise constrained 144 devices, it is not always easy to embed all the necessary features. 146 Historically, there has been a trend to invent special "light-weight" 147 _protocols_ to connect the most constrained devices. However, much 148 of this development can simply run on existing Internet protocols, 149 provided some attention is given to achieving light-weight 150 _implementations_. In some cases the new, constrained environments 151 can indeed benefit from protocol optimizations and additional 152 protocols that help optimize Internet communications and lower the 153 computational requirements. Examples of IETF standardization efforts 154 targeted for these environments include the "IPv6 over Low power WPAN 155 (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and 156 "Constrained RESTful Environments (CoRE)" working groups. More 157 generally, however, techniques are required to implement both these 158 optimized protocols as well as the other protocols of the Internet 159 protocol suite in a way that makes them applicable to a wider range 160 of devices. 162 1.1. Objectives 164 The present document, a product of the IETF Light-Weight 165 Implementation Guidance (LWIG) Working Group, focuses on helping the 166 implementers of the smallest devices. The goal is to be able to 167 build minimal yet interoperable IP-capable devices for the most 168 constrained environments. 170 Building a small implementation does not have to be hard. Many small 171 devices use stripped down versions of general purpose operating 172 systems and their TCP/IP stacks. However, there are implementations 173 that go even further in minimization and can exist in as few as a 174 couple of kilobytes of code, as on some devices this level of 175 optimization is necessary. Technical and cost considerations may 176 limit the computing power, battery capacity, available memory, or 177 communications bandwidth that can be provided. To overcome these 178 limitations the implementers have to employ the right hardware and 179 software mechanisms. For instance, certain types of memory 180 management or even fixed memory allocation may be required. It is 181 also useful to understand what is necessary from the point of view of 182 the communications protocols and the application employing them. For 183 instance, a device that only acts as a client or only requires one 184 connection can simplify its TCP implementation considerably. 186 The purpose of this document is to collect experiences from 187 implementers of IP stacks in constrained devices. The focus is on 188 techniques that have been used in actual implementations and do not 189 impact interoperability with other devices. The techniques shall 190 also not affect conformance to the relevant specifications. We 191 describe implementation techniques for reducing complexity, memory 192 footprint, or power usage. 194 The topics for this working group will be chosen from Internet 195 protocols that are in wide use today, such as IPv4 and IPv6; UDP and 196 TCP; ICMPv4/v6, MLD/IGMP and ND; DNS and DHCPv4/v6; TLS, DTLS and 197 IPsec; as well as from the optimized protocols that result from the 198 work of the 6LoWPAN, RPL, and CoRE working groups. This document 199 will be helpful for the implementers of new devices or for the 200 implementers of new general-purpose small IP stacks. It is also 201 expected that the document will increase our knowledge of what 202 existing small implementations do, and will help in the further 203 optimization of the existing implementations. In areas where the 204 considerations for small implementations have already been documented 205 in an accessible way, we will refer to those documents instead of 206 duplicating the material here. 208 Generic hardware design advice and software implementation techniques 209 are outside the scope of this document. Protocol implementation 210 experience, however, is the focus. There is no intention to describe 211 any new protocols or protocol behavior modifications beyond what is 212 already allowed by existing RFCs, because it is important to ensure 213 that different types of devices can work together. For example, 214 implementation techniques relating to security mechanisms are within 215 scope, but mere removal of security functionality from a protocol is 216 rarely an acceptable approach. 218 1.2. Call for contributions 220 The present draft of the document is an outline that will grow with 221 the contributions received, which are expressly invited. As this 222 document focuses on experience from existing implementations, this 223 requires implementer input; in particular, participation is required 224 from the implementers of existing small IP stacks. "Small" here is 225 intended to be applicable approximately to what is described in 226 Section 2 -\u002D where it is more important that the technique 227 described is grounded in actual experience than that the experience 228 is actually from a (very) constrained system. 230 Only a few subsections are fleshed out in this initial draft; 231 additional subsections will quickly be integrated from additional 232 contributors. 234 1.3. Terminology used in this document 236 The present document has originally also been used to develop 237 pertinent terminology. This has been factored out into a separate 238 document, [I-D.ietf-lwig-terminology], which is now a prerequisite to 239 reading the present document. 241 1.4. Scope of the present document 243 Using this terminology, we can now more precisely define the scope of 244 the present document: 246 This document is about implementation techniques that enable 247 constrained nodes to form constrained node networks. 249 Delay-Tolerant Networks (DTNs) are out of scope. (See Section 1.1 250 above for a further list of non-goals.) 252 1.5. Terminology boilerplate 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 256 document are to be interpreted as described in RFC 2119. As this is 257 an informational document, the [RFC2119] keywords will only be used 258 to underscore requirements where similar key words apply in the 259 context of the specifications the light-weight implementation of 260 which is being discussed. 262 The term "byte" is used in its now customary sense as a synonym for 263 "octet". 265 2. Drawing the Landscape 267 There is not a single kind of constrained, Internet-connected device. 268 To the contrary, the trend is towards much more functional variety of 269 such devices than is customary today in the Internet. The 270 terminology document [I-D.ietf-lwig-terminology] introduces a number 271 of terms that will be used here to locate some of the technique 272 described in the following sections within certain areas of 273 applications. 275 2.1. Design Objectives 277 o Consideration for design or implementation approaches for 278 implementation of IP stacks for constrained devices will be 279 impacted by the RAM usage for these designs. Here the 280 consideration is what is the best approach to minimize overhead. 282 o In addition, the impact on throughput in terms of IP protocol 283 implementation must take into consideration the methods that 284 minimize overhead but balance performance requirements for the 285 light-weight constrained devices. 287 o Protocol implementation must consider its impact on CPU 288 utilization. Here guidance will be provided on how to minimize 289 tasks that require additional CPU execution time. 291 How does the implementation of the IP stack effect the application 292 both in terms of performance but also of those same attributes and 293 requirements (RAM, CPU usage, etc.) that we are examining for the IP 294 protocol stack? 296 From performing a synthesis of implementation experiences we will be 297 able to understand and document the benefits and consequences of 298 varied approaches. Scaling code and selected approaches in terms of 299 scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for 300 the approach will aid in the development of single code base when 301 possible. 303 2.2. Implementation Styles 305 Compared to personal computing devices, constrained devices tend to 306 make use of quite different classes of operating systems, if that 307 term is even applicable. 309 ... 311 o Single-threaded/giant mainloop 313 o Event-driven vs. threaded/blocking 315 * The usual multi-threaded model blocks a thread on primitives 316 such as connect(), accept() or read() until an external event 317 takes place. This model is often thought to consume too much 318 RAM and CPU processing. 320 * The event driven model uses a non-blocking approach: E.g., when 321 an application interface sends a message, the routine would 322 return immediately (before the message is sent). A call-back 323 facility notifies the application or calling code when the 324 desired processing is completed. Here the benefit is that no 325 thread context needs to be preserved for long periods of time. 327 o Single/multiple processing elements 329 o E.g., separate radio/network processor 331 Introduce these briefly: Some techniques may be applicable only to 332 some of these styles! 334 2.3. Roles of nodes 336 Constrained nodes are by necessity more specialized than general 337 purpose computing devices; they may have a quite specific role. Some 338 implementation techniques may also 340 o Constrained nodes 342 o Nodes talking to constrained nodes 344 o Gateways/Proxies 346 In all these cases, constrained nodes that are "sleepy" pose 347 additional considerations. (Explain sleepy...) E.g., a node talking 348 to a sleepy node may need to make special arrangements; this is even 349 more true where a gateway or proxy interfaces the general Internet 351 o Bandwidth/latency considerations 353 2.4. Overview over the document 355 The following sections will first go through a number of specific 356 protocol layers, starting from layers of the data plane (link 357 adaptation, network, transport, application), followed by control 358 plane protocol layers (link layer support, network layer and routing, 359 host configuration and lookup services). We then look at security 360 protocols (general cryptography considerations, transport layer 361 security, network layer security, network access control). Finally, 362 we discuss some specific, cross-layer concerns, some "wire-visible", 363 some of concern within a specific implementation. Clearly, many 364 topics could be discussed in more than one place in this structure. 365 The objective is not to have something for each of the potential 366 topics, but to document the most valuable experience that may be 367 available. 369 3. Data Plane Protocols 371 3.1. Link Adaptation Layer 373 6LoWPAN 375 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration 377 Author: Carsten Bormann 379 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its 380 minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical 381 layer MTU of only 127 bytes (some of which are taken by MAC layer and 382 adaptation layer headers). Therefore, the adaptation layer provides 383 a fragmentation and reassembly scheme that can fragment a single IPv6 384 packet of up to 1280 bytes into multiple adaptation layer fragments 385 of up to 127 bytes each (including MAC and adaptation layer 386 overhead). 388 In a route-over configuration, implementing this adaptation layer 389 fragmentation scheme straightforwardly means that reassembly and then 390 fragmentation are performed at each forwarding hop. As fragments 391 from several packets may be arriving interleaved with each other, 392 this approach requires buffer space for multiple MTU-size IPv6 393 packets. 395 In a mesh-under configuration, adaptation layer fragments can be 396 forwarded independently of each other. It would be preferable if 397 something similar were possible for route-over. Complete 398 independence in forwarding of adaptation layer fragments is not 399 possible for route-over, however, as the layer-3 addresses needed for 400 forwarding are in the initial bytes of the IPv6 header, which is 401 present only in the first fragment of a larger packet. 403 Instead of performing a full reassembly, implementations may be able 404 to optimize this process by not keeping a full reassembly buffer, but 405 just a runt buffer (called "virtual reassembly buffer" in [WEI]) for 406 each IP packet. This buffer caches only the datagram_tag field (as 407 usual combined with the sender's link layer address, the 408 destination's link layer address and the datagram_size field) and the 409 IPv6 header including the relevant addresses. Initial fragments are 410 then forwarded independently (after header decompression/compression) 411 and create a runt reassembly buffer. Non-initial fragments (which 412 don't require header decompression/compression in 6LoWPAN) are 413 matched against the runt buffers by datagram_tag etc. and forwarded 414 if an IPv6 address is available. (This simple scheme may be 415 complicated a bit if header decompression/compression of the initial 416 fragment causes an overflow of the physical MTU; in this case some 417 overflow data may need to be stored in the runt buffers to be 418 combined with further fragments or may simply be forwarded as a 419 separate additional fragment.) 421 If non-initial fragments arrive out of order before the initial 422 fragment, a route-over router may want to keep the contents of the 423 non-initial fragments until the initial fragment is available, which 424 does need some buffer space. If that is not available, a more 425 constrained route-over router may simply discard out-of order non- 426 initial fragments, possibly taking note that there is no point in 427 forwarding any more fragments with the same combination of 6LoWPAN 428 datagram_tag field, L2 addresses and datagram_size. 430 Runt buffers should time out like full reassembly buffers, and may 431 either keep a map of fragments forwarded or they may simply be 432 removed upon forwarding the final fragment, assuming that no out-of- 433 order fragments will follow. 435 3.1.1.1. Implementation Considerations for Not-So-Constrained Nodes 437 [RFC4944] makes no explicit mandates about the order in which 438 fragments should be sent. Because it is heavily favored by the above 439 implementation techniques, it is highly advisable for all 440 implementations to always send adaptation layer fragments in natural 441 order, i.e., starting with the initial fragment, continuing with 442 increasing datagram_offset. 444 3.2. Network Layer 446 IPv4 and IPv6 448 3.3. Transport Layer 450 TCP and UDP 452 Both TCP and UDP employ 16-bit one's-complement checksums to protect 453 against transmission errors. A number of RFCs discuss efficient 454 implementation techniques for computing and updating Internet 455 Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet 456 Checksum, as opposed to computing it from scratch, may be of interest 457 where a pre-computed packet is provided, e.g., in Flash ROM, and a 458 copy is made in RAM and updated with some current values, or when the 459 actual transmitted packet is composed from pre-defined parts in ROM 460 and new parts in RAM.) 462 3.3.1. TCP 464 Ed. Note: 466 The following outline of a section is an attempt to provide 467 substructure for a future discussion of TCP-related issues based on 468 the TCP Roadmap, [RFC4614]. The indented text, as well as the RFC 469 citations, are copied (and redacted) from there; this certainly needs 470 to be refined in a future version. (Some additional adaptation of 471 the material may also be required as RFC 2581 was since obsoleted by 472 RFC 5681, and RFC 3782 was obsoleted by RFC 6582.) 474 Author: Yuanchen Ma 476 In [RFC4614], the TCP related RFCs are summarized. Some RFCs 477 describe absolutely required TCP behaviors for proper functioning and 478 interoperability. Further RFCs describe strongly encouraged, but 479 non-essential, behaviors. There are also experimental extensions 480 that are not yet standard practices, but that potentially could be in 481 the future. 483 In this subsection, the influence of resource constrained nodes on 484 TCP implementations are summarized according to the lists of 485 [RFC4614]. 487 3.3.1.1. Absolutely required TCP behaviors for proper functioning and 488 interoperability 490 RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) 492 In RFC793, the TCP state machine and event processing, and TCP's 493 semantics for data transmission, reliability, flow control, 494 multiplexing, and acknowledgment. For this part, the constraint of 495 memory will limit the multiplexing capability of TCP. /_text needed 496 for RFC793_/ 498 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 499 (October 1989) 501 RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification 502 (December 1998) 504 RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) 506 This document [RFC2873] removes from the TCP specification all 507 processing of the precedence bits of the TOS byte of the IP 508 header. 510 These three RFCs mandate the support for IPv6 and TOS in IP header, 511 which are a must for resource constrained node to implement. 513 RFC 2581 S: "TCP Congestion Control" (April 1999) 515 Although RFC 793 did not contain any congestion control 516 mechanisms, today congestion control is a required component of 517 TCP implementations. This document [RFC2581] defines the current 518 versions of Van Jacobson's congestion avoidance and control 519 mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. RFC 520 2001 was a conceptual precursor that was obsoleted by RFC 2581. 522 A number of behaviors that together constitute what the community 523 refers to as "Reno TCP" are described in RFC 2581. 525 RFC 1122 mandates the implementation of a congestion control 526 mechanism, and RFC 2581 details the currently accepted mechanism. 527 RFC 2581 differs slightly from the other documents listed in this 528 section, as it does not affect the ability of two TCP endpoints to 529 communicate; however, congestion control remains a critical 530 component of any widely deployed TCP implementation and is 531 required for the avoidance of congestion collapse and to ensure 532 fairness among competing flows. 534 RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) 536 Abstract: "This document defines the standard algorithm that 537 Transmission Control Protocol (TCP) senders are required to use to 538 compute and manage their retransmission timer. 540 3.3.1.2. Strongly encouraged, but non-essential, behaviors of TCP 542 RFC 1323 S: "TCP Extensions for High Performance" (May 1992) 544 This document [RFC1323] defines TCP extensions for window scaling, 545 timestamps, and protection against wrapped sequence numbers, for 546 efficient and safe operation over paths with large bandwidth-delay 547 products. 549 RFC 2675 S: "IPv6 Jumbograms" (August 1999) 551 IPv6 supports longer datagrams than were allowed in IPv4. 553 RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) 554 to IP" (September 2001) 556 3.3.1.2.1. Congestion Control and Loss Recovery Extensions 558 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 559 (January 2001) 561 Abstract: "This document proposes Limited Transmit, a new 562 Transmission Control Protocol (TCP) mechanism that can be used to 563 more effectively recover lost segments when a connection's 564 congestion window is small 566 RFC 3390 S: "Increasing TCP's Initial Window" (October 2002) 568 This document [RFC3390] updates RFC 2581 to permit an initial TCP 569 window of three or four segments during the slow-start phase, 570 depending on the segment size. 572 RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery 573 Algorithm" (April 2004) 575 This document [RFC3782] specifies a modification to the standard 576 Reno fast recovery algorithm, whereby a TCP sender can use partial 577 acknowledgments to make inferences determining the next segment to 578 send in situations where SACK would be helpful but isn't 579 available. 581 3.3.1.2.2. SACK-Based Loss Recovery and Congestion Control 583 RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) 585 This document [RFC2018] defines the basic selective acknowledgment 586 (SACK) mechanism for TCP. 588 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 589 Option for TCP" (July 2000) 591 This document [RFC2883] extends RFC 2018 to cover the case of 592 acknowledging duplicate segments. 594 RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based 595 Loss Recovery Algorithm for TCP" (April 2003) 597 3.3.1.2.3. Dealing with Forged Segments 599 RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996) 601 RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature 602 Option" (August 1998) 604 3.3.1.3. Experimental extensions that are not yet standard practices 606 The experimental extensions are not mature yet. The contents need to 607 be validated to be safe and logical behavior. It is not recommended 608 for the resource constrained node to implement. 610 3.3.1.4. Others 612 RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) 614 From abstract: "This memo catalogs several known Transmission 615 Control Protocol (TCP) implementation problems dealing with Path 616 Maximum Transmission Unit Discovery (PMTUD), including the long- 617 standing black hole problem, stretch acknowlegements (ACKs) due to 618 confusion between Maximum Segment Size (MSS) and segment size, and 619 MSS advertisement based on PMTU." [RFC2923] 621 3.4. Application Layer 623 3.4.1. General considerations about Application Programming Interfaces 624 (APIs) 626 Author: Carl Williams 628 Constrained devices are not necessarily in a position to use APIs 629 that would be considered "standard" for less constrained environments 630 (e.g., Berkeley sockets or those defined by POSIX). 632 When an API implements a protocol, this can be based on proxy methods 633 for remote invocations that underneath rely on the communication 634 protocol. One of the roles of the API can be exactly to hide the 635 detail of the transport protocol. 637 Changes to the lower layers will be made to implement light-weight 638 stacks so this impacts that implementation and inter-workings with 639 the API. Similar considerations such as RAM, CPU utilization and 640 performance requirements apply to the API and its use of the lower 641 layer resources (i.e., buffers). 643 Considerations for the proper approach for a developer to request 644 services from an application program need to be explored and 645 documented. Such considerations will allow the progression of a 646 common consistent networking paradigm without inventing a new way of 647 programming these devices. 649 In addition, such considerations will take into account the inter- 650 working of the API with the protocols. Protocols are more complex to 651 use as they are less direct and take a lot of serializing, de- 652 serializing and dispatching type logic. 654 So the connection of the API and the protocols on a constrained 655 device becomes even more important to balance the requirements of 656 RAM, CPU and performance. 658 _** Here we will proceed to collect and document ... insert 659 experiences from existing API on constrained devices (TBD) **_ 661 3.4.2. Constrained Application Protocol (CoAP) 663 Author: Olaf Bergmann 665 The Constrained Application Protocol [I-D.ietf-core-coap] has been 666 designed specifically for machine-to-machine communication in 667 networks with very constrained nodes. Typical application scenarios 668 therefore include building automation and the Internet of Things. 670 The major design objectives have been set on small protocol overhead, 671 robustness against packet loss, and high latency induced by small 672 bandwidth shares or slow request processing in end nodes. To 673 leverage integration of constrained nodes with the world-wide 674 Internet, the protocol design was led by the architectural style that 675 accounts for the scalability and robustness of the Hypertext Transfer 676 Protocol [RFC2616]. 678 Lightweight implementations benefit from this design in many 679 respects: First, the use of Uniform Resource Identifiers (URIs) for 680 naming resources and the transparent forwarding of their 681 representations in a server-stateless request/response protocol make 682 protocol-translation to HTTP a straightforward task. Second, the set 683 of protocol elements that are inevitable for the core protocol and 684 thus must be implemented on every node has been kept very small to 685 avoid unnecessary accumulation of optional features. Options that 686 -\u002D when present -\u002D are critical for message processing are 687 explicitly marked as such to force immediate rejection of messages 688 with unknown critical options. Third, the syntax of protocol data 689 units is easy to parse and is carefully defined to avoid creation of 690 state in servers where possible. 692 Although these features enable lightweight implementations of the 693 Constrained Application Protocol, there is still a trade-off between 694 robustness and latency of constrained nodes on one hand and resource 695 demands (such as battery consumption, dynamic memory needs and static 696 code-size) on the other. This section gives some guidance on 697 possible strategies to solve this trade-off for very constrained 698 nodes (Class 1 in [I-D.ietf-lwig-terminology]). The main focus is on 699 servers as this is deemed the predominant case where CoAP 700 applications are faced with tight resource constraints. 702 Additional considerations for the implementation of CoAP on tiny 703 sensors are given in [I-D.arkko-core-sleepy-sensors]. 705 3.4.2.1. Message Layer Processing 707 For constrained nodes of Class 1 or even Class 2, limiting factors 708 for (wireless) network communication usually are RAM size and battery 709 lifetime. Most applications therefore try to avoid dealing with 710 fragmented packets on the network layer and minimize internal buffer 711 space for both transmit and receive operations. One of the most 712 expensive operations hence is the retransmission of messages as it 713 implies additional energy consumption for the (radio) network 714 interface and occupied RAM storage for the send buffer. 716 Where multi-threading is not an option at all because no full-fledged 717 operating system is present, all operations are triggered by a big 718 main loop in a send-receive-dispatch cycle. To implement the packet 719 retransmission, CoAP implementations at least need a separate send 720 buffer and a decent notion of time, e.g. as a strictly monotonic 721 increasing tick counter. For platforms that disable clock tick 722 interrupts in sleep states, the application must take into 723 consideration the clock deviation that occurs during sleep (or ensure 724 to remain in idle state until the message has been acknowledged or 725 the maximum number of retransmissions is reached). Since CoAP allows 726 up to four retransmissions with a binary exponential back-off it 727 could take up to 45 seconds until the send operation is complete. 728 Even in idle state, this means substantial energy consumption for 729 low-power nodes. Implementers therefore might choose a two-step 730 strategy: First, do one or two retransmissions and then, in the later 731 phases of back-off, go to sleep until the next retransmission is due. 732 In the meantime, the node could check for new messages including the 733 acknowledgement for any confirmable message to send. 735 A similar strategy holds for confirmable messages with separate 736 responses. This concept entitles CoAP servers to return an empty 737 acknowledgement to indicate that a confirmable request has been 738 understood and is being processed. Once a proper response has been 739 generate to fulfill the request, it is sent back as a confirmable 740 message as well. The server implementation in this case must be able 741 to map retransmissions of the original request to the ongoing 742 operation and provide the client-selected Token to map between 743 original request and the separate response. 745 Depending on the number of requests that can be handled in parallel, 746 an implementation might create a stub response filled with any option 747 that has to be copied from the original request to the separate 748 response, especially the Token option. The drawback of this 749 technique is that the server must be prepared to receive 750 retransmissions of the previous (confirmable) request to which a new 751 acknowledgement must be generated. If memory is an issue, a single 752 buffer can be used for both tasks: Only the message type and code 753 must be updated, changing the message id is optional. Once the 754 resource representation is known, it is added as new payload at the 755 end of the stub response. Acknowledgements still can be sent as 756 described before as long as no additional options are required to 757 describe the payload. 759 3.4.2.2. Message Parsing 761 Both CoAP clients and servers must construct outgoing CoAP PDUs and 762 parse incoming messages. The basic message header consists of only 763 four octets and thus can be mapped easily to an internal data 764 structure, considering the actual byte order of the host. Once the 765 message is accepted for further processing, the set of options 766 contained in the received message must be decoded to check for 767 unknown critical options. To avoid multiple passes through the 768 option list, the option parser might maintain a bit-vector where each 769 bit represents an option number that is present in the received 770 request. The delta-encoded option number indicates the number of 771 left-shift operations to apply on a bit mask to set the corresponding 772 bit. 774 In addition, the byte index of every option is added to a sparse list 775 (e.g. a one-dimensional array) for fast retrieval. This 776 particularly enables efficient reduced-function handling of options 777 that might occur more than once such as Uri-Path. In this 778 implementation strategy, the delta is zero for any subsequent path 779 segment, hence the stored byte index for option 9 (Uri-Path) will be 780 overwritten to hold a pointer to the last occurrence of that option, 781 i.e., only the last path component actually matters. (Of course, 782 this requires choosing resource names where the combination of (final 783 Uri-Path component, final Uri-Query component) is server-wide unique. 785 Note: Where skipping all but the last path segment is not feasible 786 for some reason, resource identification could be ensured by some 787 hash value calculated over the path segments. For each segment 788 encountered, the stored hash value is updated by the current 789 option value. This works if a cheap _perfect hashing_ scheme can 790 be found for the resource names. 792 Once the option list has been processed at least up to the highest 793 option number that is supported by the application, any known 794 critical option and all elective options can be masked out to 795 determine if any unknown critical option was present. If this is the 796 case, this information can be used to create a 4.02 response 797 accordingly. (Note that the remaining options also must be processed 798 to add further critical options included in the original request.) 800 3.4.2.3. Storing Used Message IDs 802 If CoAP is used directly on top of UDP (i.e., in NoSec mode), it 803 needs to cope with the fact that the UDP datagram transport can 804 reorder and duplicate messages. (In contrast to UDP, DTLS has its 805 own duplicate detection.) CoAP has been designed with protocol 806 functionality such that rejection of duplicate messages is always 807 possible. It is at the discretion of the receiver if it actually 808 wants to make use of this functionality. Processing of duplicate 809 messages comes at a cost, but so does the management of the state 810 associated with duplicate rejection. Hence, a receiver may have good 811 reasons to decide not to do the duplicate rejection. If duplicate 812 rejection is indeed necessary, e.g., for non-idempotent requests, it 813 is important to control the amount of state that needs to be stored. 815 Author: Esko Dijk 817 CoAP's duplicate rejection functionality can be straightforwardly 818 implemented in a CoAP end-point by storing, for each remote CoAP end- 819 point ("peer") that it communicates with, a list of recently received 820 CoAP Message IDs (MIDs) along with some timing information. A CoAP 821 message from a peer with a MID that is in the list for that peer can 822 simply be discarded. 824 The timing information in the list can then be used to time out 825 entries that are older than the _expected extent of the re-ordering_, 826 an upper bound for which can be estimated by adding the _potential 827 retransmission window_ ([I-D.ietf-core-coap] section "Reliable 828 Messages") and the time packets can stay alive in the network. 830 Such a straightforward implementation is suitable in case other CoAP 831 end-points generate random MIDs. However, this storage method may 832 consume substantial RAM in specific cases, such as: 834 o many clients are making periodic, non-idempotent requests to a 835 single CoAP server; 837 o one client makes periodic requests to a large number of CoAP 838 servers and/or requests a large number of resources; where servers 839 happen to mostly generate separate CoAP responses (not piggy- 840 backed); 842 For example, consider the first case where the expected extent of re- 843 ordering is 50 seconds, and N clients are sending periodic POST 844 requests to a single CoAP server during a period of high system 845 activity, each on average sending one client request per second. The 846 server would need 100 * N bytes of RAM to store the MIDs only. This 847 amount of RAM may be significant on a RAM-constrained platform. On a 848 number of platforms, it may be easier to allocate some extra program 849 memory (e.g. Flash or ROM) to the CoAP protocol handler process than 850 to allocate extra RAM. Therefore, one may try to reduce RAM usage of 851 a CoAP implementation at the cost of some additional program memory 852 usage and implementation complexity. 854 Some CoAP clients generate MID values by a using a Message ID 855 variable [I-D.ietf-core-coap] that is incremented by one each time a 856 new MID needs to be generated. (After the maximum value 65535 it 857 wraps back to 0.) We call this behavior "sequential" MIDs. One 858 approach to reduce RAM use exploits the redundancy in sequential MIDs 859 for a more efficient MID storage in CoAP servers. 861 Naturally such an approach requires, in order to actually reduce RAM 862 usage in an implementation, that a large part of the peers follow the 863 sequential MID behavior. To realize this optimization, the authors 864 therefore RECOMMEND that CoAP end-point implementers employ the 865 "sequential MID" scheme if there are no reasons to prefer another 866 scheme, such as randomly generated MID values. 868 Security considerations might call for a choice for 869 (pseudo)randomized MIDs. Note however that with truly randomly 870 generated MIDs the probability of MID collision is rather high in use 871 cases as mentioned before, following from the Birthday Paradox. For 872 example, in a sequence of 52 randomly drawn 16-bit values the 873 probability of finding at least two identical values is about 2 874 percent. 876 From here on we consider efficient storage implementations for MIDs 877 in CoAP end-points, that are optimized to store "sequential" MIDs. 878 Because CoAP messages may be lost or arrive out-of-order, a solution 879 has to take into account that received MIDs of CoAP messages are not 880 actually arriving in a sequential fashion, due to lost or reordered 881 messages. Also a peer might reset and lose its MID counter(s) state. 882 In addition, a peer may have a single Message ID variable used in 883 messages to many CoAP end-points it communicates with, which partly 884 breaks sequentiality from the receiving CoAP end-point's perspective. 885 Finally, some peers might use a randomly generated MID values 886 approach. Due to these specific conditions, existing sliding window 887 bitfield implementations for storing received sequence numbers are 888 typically not directly suitable for efficiently storing MIDs. 890 Table 1 shows one example for a per-peer MID storage design: a table 891 with a bitfield of a defined length _K_ per entry to store received 892 MIDs (one per bit) that have a value in the range [MID_i + 1 , MID_i 893 + K]. 895 +----------+----------------+-----------------+ 896 | MID base | K-bit bitfield | base time value | 897 +----------+----------------+-----------------+ 898 | MID_0 | 010010101001 | t_0 | 899 | | | | 900 | MID_1 | 111101110111 | t_1 | 901 | | | | 902 | ... etc. | | | 903 +----------+----------------+-----------------+ 905 Table 1: A per-peer table for storing MIDs based on MID\_i 907 The presence of a table row with base MID_i (regardless of the 908 bitfield values) indicates that a value MID_i has been received at a 909 time t_i. Subsequently, each bitfield bit k (0...K-1) in a row i 910 corresponds to a received MID value of MID_i + k + 1. If a bit k is 911 0, it means a message with corresponding MID has not yet been 912 received. A bit 1 indicates such a message has been received already 913 at approximately time t_i. This storage structure allows e.g. with 914 k=64 to store in best case up to 130 MID values using 20 bytes, as 915 opposed to 260 bytes that would be needed for a non-sequential 916 storage scheme. 918 The time values t_i are used for removing rows from the table after a 919 preset timeout period, to keep the MID store small in size and enable 920 these MIDs to be safely re-used in future communications. (Note that 921 the table only stores one time value per row, which therefore needs 922 to be updated on receipt of another MID that is stored as a single 923 bit in this row. As a consequence of only storing one time value per 924 row, older MID entries typically time out later than with a simple 925 per-MID time value storage scheme. The end-point therefore needs to 926 ensure that this additional delay before MID entries are removed from 927 the table is much smaller than the time period after which a peer 928 starts to re-use MID values due to wrap-around of a peer's MID 929 variable. One solution is to check that a value t_i in a table row 930 is still recent enough, before using the row and updating the value 931 t_i to current time. If not recent enough, e.g. older than N 932 seconds, a new row with an empty bitfield is created.) [Clearly, 933 these optimizations would benefit if the peer were much more 934 conservative about re-using MIDs than currently required in the 935 protocol specification.] 937 The optimization described is less efficient for storing randomized 938 MIDs that a CoAP end-point may encounter from certain peers. To 939 solve this, a storage algorithm may start in a simple MID storage 940 mode, first assuming that the peer produces non-sequential MIDs. 941 While storing MIDs, a heuristic is then applied based on monitoring 942 some "hit rate", for example, the number of MIDs received that have a 943 Most Significant Byte equal to that of the previous MID divided by 944 the total number of MIDs received. If the hit rate tends towards 1 945 over a period of time, the MID store may decide that this particular 946 CoAP end-point uses sequential MIDs and in response improve 947 efficiency by switching its mode to the bitfield based storage. 949 3.4.3. (Other Application Protocols...) 951 4. Control Plane Protocols 953 4.1. Link Layer Support 955 ARP, ND; 6LoWPAN-ND 957 4.2. Network Layer 958 ICMP, ICMPv6, IGMP/MLD 960 4.3. Routing 962 RPL, AODV/DYMO, OLSRv2 964 4.4. Host Configuration and Lookup Services 966 DNS, DHCPv4, DHCPv6 968 4.5. Network Management 970 SNMP, netconf? 972 4.5.1. SNMP 974 Author: Brinda M C 976 This section describes an approach for developing a light-weight SNMP 977 agent for resource constrained devices running the 6LoWPAN/RPL 978 protocol stack. The motivation for the work is driven by two major 979 factors: 981 o SNMP plays a vital role in monitoring and managing any operational 982 network; 6LoWPAN based WSN is no exception to this. 984 o There is a need for building a light-weight SNMP agent which 985 consumes less memory and less computational resources. 987 The following subsections are organized as follows: 989 o Section 4.5.1.1 provides some background. 991 o In Section 4.5.1.2, we revisit existing SNMP implementation in the 992 context of memory constrained devices. 994 o In Section 4.5.1.3, we present our approach for building a memory 995 efficient SNMP agent. 997 o Using a realistic example, in Section 4.5.1.4, we illustrate how 998 the proposed method can be implemented. 1000 o In Section 4.5.1.5, we explore a few ideas which can further help 1001 in improving the memory utilization. 1003 4.5.1.1. Background 1004 Our initial SNMP agent implementation was completely based on Net- 1005 SNMP, well-known open-source network monitoring and management 1006 software. After porting the agent on to the TelosB mote, we observed 1007 that it occupies a text program memory of more than 8 KiB on TinyOS 1008 and Contiki OS platforms. (Note that both these platforms already 1009 use compiler optimizations to minimize the memory footprint.) 8 KiB 1010 is already non-negligible given the 48 KiB program memory limit of 1011 TelosB. Added to this, the memory taken up by 6LoWPAN and the 1012 related protocol stacks are ever growing, causing serious memory 1013 crunch in the resource constrained devices. We reached a situation 1014 where we could not build an image on the TinyOS/Contiki OS platforms 1015 with our SNMP agent. 1017 We came across SNMPv1 agent implementations elsewhere in the 1018 literature which also report similar memory consumption. This 1019 motivated us to have a re-look at the existing SNMP agent 1020 implementation, and explore the possibility of an alternate 1021 implementation using altogether a different approach. 1023 4.5.1.2. Revisiting SNMP implementation for resource constrained 1024 devices 1026 If we look at a typical SNMP agent implementation, we can see that 1027 much of the memory consuming code is pertaining to ASN.1 related SNMP 1028 PDU parsing and SNMP PDU build operations. The SNMP parsing mainly 1029 recovers various fields from the incoming PDU, such as the OIDs, 1030 whereas the SNMP PDU build is the reverse operation of building the 1031 response PDU from the OIDs. 1033 The key observation is that, for a given MIB definition, an OID of 1034 interest contained in the incoming SNMP PDU is already available, 1035 albeit in an encoded form. This enables identifying the OID from the 1036 packet in its "raw" form, simplifying parser operation. 1038 We also can make use of this observation while building the response 1039 SNMP PDU. For a given MIB definition, we can think of statically 1040 having a pre-composed ASN.1 encoded version of OIDs, and use them 1041 while constructing the response SNMP PDU. 1043 4.5.1.3. Proposed approach for building an memory efficient SNMP agent 1045 As noted in the previous section, since an SNMP OID is already 1046 _contained_ in the incoming network PDU, we came up with a simple OID 1047 signature identification method performed directly on the network PDU 1048 through simple memory comparisons and table look-ups. Once the OID 1049 has been identified from the packet "in situ", the corresponding per- 1050 OID processing is carried out. Through this scheme we completely 1051 eliminated expensive SNMP parse operations. 1053 For the SNMP PDU build, we use _pre-encoded_ OID variables which can 1054 simply be plugged into the network SNMP response packet directly 1055 depending on the request OID. Now that the expensive build operation 1056 is taken care, what remains is the construction of the overall SNMP 1057 pdu which can be built through simple logic. Through this scheme we 1058 completely eliminated expensive SNMP build operations. 1060 Based on these ideas, we have re-architected our original SNMP agent 1061 implementation and with our new implementation we were able to bring 1062 down its text memory usage all the way down to 4 KiB from the native 1063 SNMP agent implementation which occupied 8 KiB. 1065 4.5.1.3.1. Discussion on memory usage 1067 With respect to the memory usage, while we have achieved major 1068 reduction in terms of text program memory, which occupies a major 1069 chunk of memory, a question might come to mind with regard to the 1070 static memory allocation for maintaining the tables. We found that 1071 this is not very significant to start with. Through an efficient 1072 table representation, we further optimized the memory consumption. 1073 We could do so because a typical OID description is mainly dominated 1074 by a fixed part of the hierarchy. This enables us to define few 1075 static prefixes, each corresponding to a particular hierarchy level 1076 of the OID. In the context of 6LoWPAN, it can be expected that the 1077 number of hierarchy levels will be small. 1079 4.5.1.4. Example 1081 This section illustrates the simplicity and practicality of our 1082 approach with an example. Let us consider the fragment of a 1083 representative MIB definition depicted in Figure 1 1085 iso 1086 | 1087 org 1088 | 1089 dod 1090 | 1091 internet 1092 | 1093 mgmt.mib-2 1094 | 1095 lowpanMIB 1096 | 1097 +--lowpanPrimaryStatistics(10) 1098 | 1099 +--PrimeStatsEntry(1) 1100 | 1101 +-- -R-- INTEGER lowpanMoteBatteryVoltageP(1) 1102 +-- -R-- Counter lowpanFramesReceivedP(2) 1103 +-- -R-- Counter lowpanFramesSentP(3) 1104 +-- -R-- Counter ipv6ForwardedMsgP(4) 1105 +-- -R-- Counter OUTSolicitationP(5) 1106 +-- -R-- Counter OUTAdvertisementP(6) 1108 Figure 1: A fragment of a MIB hierarchy 1110 4.5.1.4.1. Optimized SNMP Parsing 1112 Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP 1113 and lowpanFramesSentP. Corresponding to these OIDs, a C array dump 1114 of the network PDU of SNMP packet with two OIDs in a variable binding 1115 would look as in Figure 2. 1117 char snmp_get_req_pkt[] = { 1118 0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06, 1119 0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30, 1120 0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01, 1121 0x00, 0x02, 0x01, 0x00, 0x30, 0x22, 0x30, 0x0f, 1122 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1123 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00, 0x30, 1124 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 1125 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00 }; 1127 Figure 2: An SNMP packet, represented in C 1129 Inspecting the above packet, we see that the main components of the 1130 PDU are: 1132 1. Version (SNMPv1): [0x02, 0x01, 0x00] 1134 2. Community Name ("public"): [0x04, 0x06, 0x70, 0x75, 0x62, 0x6c, 1135 0x69, 0x63] 1137 3. ASN.1 encoded OIDs for lowpanMoteBatteryVoltageP, and 1138 lowpanFramesReceivedP: 1140 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1141 0x90, 0x12, 0x0a, 0x01, 0x01, 0x05, 0x00] 1143 * [0x30, 0x0f, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x01, 0x83, 1144 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00] 1146 There is a significant overlap between the two OIDs, which can be 1147 used to simplify the parsing process. We can, for instance, define 1148 one statically initialized array containing elements common between 1149 these OIDs. Using this notion of common prefix idea, we can come up 1150 with an optimized table and the OID identification then boils down to 1151 simple memory comparisons within this table. The optimized table 1152 construction will also result in scalability. 1154 4.5.1.4.2. Optimized SNMP Build 1156 Extending the same approach as described above, we can build the GET 1157 response by plugging in pre-encoded OIDs into the response packets. 1158 So, corresponding to the GET request for the OIDs as given in section 1159 4.1, we can define C arrays containing pre-encoded OIDs which can go 1160 into the response packet as in Figure 3. 1162 pdu_batt_volt[] = { 1163 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1164 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02, 1165 0x02, 0x00, 0x00 }; 1167 pdu_frames_sent[] = { 1168 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 1169 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x03, 0x41, 1170 0x02, 0x00, 0x00 }; 1172 Figure 3: Pre-encoded OIDs 1174 Since the ASN.1 basic encoding rules are in TLV format, the offset 1175 within the encoded OID where the value needs to be filled-in can be 1176 obtained from the length field. 1178 The table size optimization discussed in the previous section can be 1179 applied here, too. 1181 Note: Though we have taken a simple example to illustrate the 1182 efficacy of the proposed approach, the ideas presented here can 1183 easily be extended to other scenarios as well. 1185 4.5.1.5. Further improvements 1187 A few simple methods can reduce the code size as well as generate 1188 computationally inexpensive code. These methods might sound obvious 1189 and trivial but are important for constrained devices. 1191 o If possible, avoid using memory consuming data types such as 1192 floating point while representing a monitored variable when an 1193 equivalent representation of the same that occupies less memory is 1194 adequate. For example, while a battery voltage indication could 1195 take a fractional value between 0 and 3 V, opt for an 8-bit 1196 quantized value. 1198 o Using meta data in the MIB definition instead of absolute numbers 1199 can bring down the memory and processing significantly and can 1200 improve scalability too especially for a large scale WSN 1201 deployments. Using the same example of battery voltage, one might 1202 think of an OID which represents fewer levels of the battery 1203 voltage signifying high, medium, low, very low. 1205 o While a multi-level hierarchy for MIB definition might improve OID 1206 segregation the flip side is that it increases the overall length 1207 of the OID and results in extra memory and processing overhead. 1208 One may have to make a judicious choice while coming up with the 1209 MIB. 1211 4.5.1.6. Conclusion 1213 This subsection proposes a simple SNMP packet processing based 1214 approach for building a light-weight SNMP agent. While there is 1215 scope for further improvement, we believe that the proposed method 1216 can be a reasonably good starting point for resource constrained 1217 6LoWPAN based networks. 1219 5. Security protocols 1221 5.1. Cryptography for Constrained Devices 1223 5.2. Transport Layer Security 1225 TLS, DTLS, ciphersuites, certificates 1227 5.3. Network Layer Security 1229 IPsec, IKEv2, transforms 1231 Advice for a minimal implementation of IKEv2 can be found in 1232 [I-D.kivinen-ipsecme-ikev2-minimal]. 1234 5.4. Network Access Control 1236 (PANA, EAP, EAP methods) 1238 5.4.1. PANA 1240 Author: Mitsuru Kanda 1242 PANA [RFC5191] provides network access authentication between clients 1243 and access networks. The PANA protocol runs between a PANA Client 1244 (PaC) and a PANA Authentication Agent (PAA). PANA carries UDP 1245 encapsulated EAP [RFC3748] and includes various operational options. 1247 From the point of view of minimal implementation, some of these are 1248 not necessary for constrained devices. This section describes a 1249 minimal PANA implementation for these devices. 1251 The minimization objective for this implementation mainly targets 1252 PaCs because constrained devices often are installed as network 1253 clients, such as sensors, metering devices, etc. 1255 5.4.1.1. PANA AVPs 1257 Each PANA message can carry zero or more AVPs (Attribute-Value Pairs) 1258 within its payload. [RFC5191] specifies nine types of AVPs (AUTH, 1259 EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm, 1260 Result-Code, Session-Lifetime, and Termination-Cause). All of them 1261 are required by all minimal implementations. But there are some 1262 notes. 1264 Integrity-Algorithm AVP and PRF-Algorithm AVP: 1266 All PANA implementations MUST support AUTH_HMAC_SHA1_160 for PANA 1267 message integrity protection and PRF_HMAC_SHA1 for pseudo-random 1268 function (PRF) specified in [RFC5191]. Both of these are based on 1269 SHA-1, which therefore needs to be implemented in a minimal 1270 implementation. 1272 Nonce AVP: 1274 As the basic hash function is SHA-1, including a nonce of 20 bytes in 1275 the Nonce AVP is appropriate ([RFC5191], section 8.5). 1277 5.4.1.2. PANA Phases 1279 A PANA session consists of four phases -\u002D Authentication and 1280 authorization phase, Access phase, Re-Authentication phase, and 1281 Termination phase. 1283 Authentication and authorization phase: 1285 There are two types of PANA session initiation, PaC-initiated session 1286 and PAA-initiated session. The minimal implementation must support 1287 PaC-initiated session and does not need to support PAA-initiated 1288 session. Because a PaC (a constrained device) which may be a 1289 sleeping device, can not receive an unsolicited PANA-Auth-Request 1290 message from a PAA (PAA-initiated session). 1292 EAP messages can be carried in PANA-Auth-Request and PANA-Auth-Answer 1293 messages. In order to reduce the number of messages, "Piggybacking 1294 EAP" is useful. Both the PaC and PAA should include EAP-Payload AVP 1295 in each of PANA-Auth-Request and PANA-Auth-Answer messages as much as 1296 possible. Figure 4 shows an example "Piggybacking EAP" sequence of 1297 the Authentication and authorization phase. 1299 PaC PAA Message(sequence number)[AVPs] 1300 --------------------------------------------------------------------- 1301 -----> PANA-Client-Initiation(0) 1302 <----- PANA-Auth-Request(x)[PRF-Algorithm,Integrity-Algorithm] 1303 // The 'S' (Start) bit set 1304 -----> PANA-Auth-Answer(x)[PRF-Algorithm, Integrity-Algorithm] 1305 // The 'S' (Start) bit set 1306 <----- PANA-Auth-Request(x+1)[Nonce, EAP-Payload] 1307 -----> PANA-Auth-Answer(x+1)[Nonce, EAP-Payload] 1308 <----- PANA-Auth-Request(x+2)[EAP-Payload] 1309 -----> PANA-Auth-Answer(x+2)[EAP-Payload] 1310 <----- PANA-Auth-Request(x+3)[Result-Code, EAP-Payload, 1311 Key-Id, Session-Lifetime, AUTH] 1312 // The 'C' (Complete) bit set 1313 -----> PANA-Auth-Answer(x+3)[Key-Id, AUTH] 1314 // The 'C' (Complete) bit set 1316 Figure 4: Example sequence of the Authentication and authorization 1317 phase for a PaC-initiated session (using "Piggybacking EAP") 1319 Note: It is possible to include an EAP-Payload in both the PANA-Auth- 1320 Request and PANA-Auth-Answer messages with the 'S' bit set. But the 1321 PAA should not include an EAP-Payload in the PANA-Auth-Request 1322 message with the 'S' bit set in order to stay stateless in response 1323 to a PANA-Client-Initiation message. 1325 Access phase: 1327 After Authentication and authorization phase completion, the PaC and 1328 PAA share a PANA Security Association (SA) and move Access phase. 1329 During Access phase, [RFC5191] describes both the PaC and PAA can 1330 send a PANA-Notification-Request message with the 'P' (Ping) bit set 1331 for the peer's PANA session liveness check (a.k.a "PANA ping"). From 1332 the minimal implementation point of view, the PAA should not send a 1333 PANA-Notification-Request message with the 'P' (Ping) bit set to 1334 initiate PANA ping since the PaC may be sleeping. The PaC does not 1335 need to send a PANA-Notification-Request message with the 'P' (Ping) 1336 bit set for PANA ping to the PAA periodically and may omit the PANA 1337 ping feature itself if the PaC can detect the PANA session failure by 1338 other methods, for example, network communication failure. In 1339 conclusion, the PaC does not need to implement the periodic liveness 1340 check feature sending PANA ping but a PaC that is awake should 1341 respond to a incoming PANA-Notification-Request message with the 'P' 1342 (Ping) bit set for PANA ping as possible. 1344 Re-Authentication phase: 1346 Before PANA session lifetime expiration, the PaC and PAA MUST re- 1347 negotiate to keep the PANA session. This means that the PaC and PAA 1348 enter Re-Authentication phase. Also in the Authentication and 1349 authorization phase, there are two types of re-authentication. The 1350 minimal implementation must support PaC-initiated re-authentication 1351 and does not need to support PAA-initiated re-authentication (again 1352 because the PaC may be a sleeping device). "Piggybacking EAP" is 1353 also useful here and should be used as well. Figure 5 shows an 1354 example "Piggybacking EAP" sequence of the Re-Authentication phase. 1356 PaC PAA Message(sequence number)[AVPs] 1357 --------------------------------------------------------------------- 1358 -----> PANA-Notification-Request(q)[AUTH] 1359 // The 'A' (re-Authentication) bit set 1360 <----- PANA-Notification-Answer(q)[AUTH] 1361 // The 'A' (re-Authentication) bit set 1362 <----- PANA-Auth-Request(p)[EAP-Payload, Nonce, AUTH] 1363 -----> PANA-Auth-Answer(p)[EAP-Payload, Nonce, AUTH] 1364 <----- PANA-Auth-Request(p+1)[EAP-Payload, AUTH] 1365 -----> PANA-Auth-Answer(p+1)[EAP-Payload, AUTH] 1366 <----- PANA-Auth-Request(p+2)[Result-Code, EAP-Payload, 1367 Key-Id, Session-Lifetime, AUTH] 1368 // The 'C' (Complete) bit set 1369 -----> PANA-Auth-Answer(p+2)[Key-Id, AUTH] 1370 // The 'C' (Complete) bit set 1372 Figure 5: Example sequence of the Re-Authentication phase for a PaC- 1373 initiated session (using "Piggybacking EAP") 1375 Termination Phase: 1377 The PaC and PAA should not send a PANA-Termination-Request message 1378 except for explicitly terminating a PANA session within the lifetime. 1379 Both the PaC and PAA know their own PANA session lifetime expiration. 1380 This means the PaC and PAA should not send a PANA-Termination-Request 1381 message when the PANA session lifetime expired because of reducing 1382 message processing cost. 1384 5.4.1.3. PANA session state parameters 1386 All PANA implementations internally keep PANA session state 1387 information for each peer. At least, all minimal implementations 1388 need to keep PANA session state parameters below (in the second 1389 column storage sizes are given in bytes): 1391 +----------------------+------------+-------------------------------+ 1392 | State Parameter | Size | Comment | 1393 +----------------------+------------+-------------------------------+ 1394 | PANA Phase | 1 | Used for recording the | 1395 | Information | | current PANA phase. | 1396 | | | | 1397 | PANA Session | 4 | | 1398 | Identifier | | | 1399 | | | | 1400 | PaC's IP address and | 6 or 18 | IP Address length (4 bytes | 1401 | UDP port number | | for IPv4 and 16 bytes for | 1402 | | | IPv6) plus 2 bytes for UDP | 1403 | | | port number. | 1404 | | | | 1405 | PAA's IP address and | 6 or 18 | IP Address length (4 bytes | 1406 | UDP port number | | for IPv4 and 16 bytes for | 1407 | | | IPv6) plus 2 bytes for UDP | 1408 | | | port number. | 1409 | | | | 1410 | Outgoing message | 4 | Next outgoing request message | 1411 | sequence number | | sequence number. | 1412 | | | | 1413 | Incoming message | 4 | Next expected incoming | 1414 | sequence number | | request message sequence | 1415 | | | number. | 1416 | | | | 1417 | A copy of the last | variable | Necessary to be able to | 1418 | sent message payload | | retransmit the message | 1419 | | | (unless it can be | 1420 | | | reconstructed on the fly). | 1421 | | | | 1422 | Retransmission | 4 | | 1423 | interval | | | 1424 | | | | 1425 | PANA Session | 4 | | 1426 | lifetime | | | 1427 | | | | 1428 | PaC nonce | 20 | Generated by PaC and carried | 1429 | | | in the Nonce AVP. | 1430 | | | | 1431 | PAA nonce | 20 | Generated by PAA and carried | 1432 | | | in the Nonce AVP. | 1433 | | | | 1434 | EAP MSK Identifier | 4 | | 1435 | | | | 1436 | EAP MSK value | *) | Generated by EAP method and | 1437 | | | used for generating | 1438 | | | PANA_AUTH_KEY. | 1439 | | | | 1440 | PANA_AUTH_KEY | 20 | Necessary for PANA message | 1441 | | | protection. | 1442 | | | | 1443 | PANA PRF algorithm | 4 | Used for generating | 1444 | number | | PANA_AUTH_KEY. | 1445 | | | | 1446 | PANA Integrity | 4 | Necessary for PANA message | 1447 | algorithm number | | protection. | 1448 +----------------------+------------+-------------------------------+ 1450 *) (Storage size depends on the key derivation algorithm.) 1452 Note: EAP parameters except for MSK have not been listed here. These 1453 EAP parameters are not used by PANA and depend on what EAP method you 1454 choose. 1456 6. Wire-Visible Constraints 1458 o Checksum 1460 o MTU 1462 o Fragmentation and reassembly 1464 o Options -\u002D implications of leaving some out 1466 o Simplified TCP optimized for LLNs 1468 o Out-of-order packets 1470 7. Wire-Invisible Constraints 1472 o Buffering 1474 o Memory management 1476 o Timers 1478 o Energy efficiency 1480 o API 1482 o Data structures 1484 o Table sizes (somewhat wire-visible) 1486 o Improved error handling due to resource overconsumption 1488 8. IANA Considerations 1490 This document makes no requirements on IANA. (This section to be 1491 removed by RFC editor.) 1493 9. Security Considerations 1495 (TBD.) 1497 10. Acknowledgements 1499 Much of the text of the introduction is taken from the charter of the 1500 LWIG working group and the invitation to the IAB workshop on 1501 Interconnecting Smart Objects with the Internet. Thanks to the 1502 numerous contributors. Angelo Castellani provided comments that led 1503 to improved text. 1505 10.1. Contributors 1507 The RFC guidelines no longer allow RFCs to be published with a large 1508 number of authors. As there are many authors that have contributed 1509 to the sections of this document, their names are listed in the 1510 individual section headings as well as alphabetically listed with 1511 their affiliations below. 1513 +------------+--------------------+---------------------------------+ 1514 | Name | Affiliation | Contact | 1515 +------------+--------------------+---------------------------------+ 1516 | Brinda M C | Indian Institute | brinda@ece.iisc.ernet.in | 1517 | | of Science | | 1518 | | | | 1519 | Carl | MCSR Labs | carlw@mcsr-labs.org | 1520 | Williams | | | 1521 | | | | 1522 | Carsten | Universitaet | cabo@tzi.org | 1523 | Bormann | Bremen TZI | | 1524 | | | | 1525 | Esko Dijk | Philips Research | esko.dijk@philips.com | 1526 | | | | 1527 | Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp | 1528 | Kanda | | | 1529 | | | | 1530 | Olaf | Universitaet | bergmann@tzi.org | 1531 | Bergmann | Bremen TZI | | 1532 | | | | 1533 | Yuanchen | Hitachi (China) | ycma@hitachi.cn | 1534 | Ma | R&D Corporation | | 1535 | | | | 1536 | ... | ... | | 1537 +------------+--------------------+---------------------------------+ 1539 11. References 1541 11.1. Normative References 1543 [I-D.ietf-lwig-terminology] 1544 Bormann, C. and M. Ersue, "Terminology for Constrained 1545 Node Networks", draft-ietf-lwig-terminology-00 (work in 1546 progress), February 2013. 1548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1549 Requirement Levels", BCP 14, RFC 2119, March 1997. 1551 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1552 "Transmission of IPv6 Packets over IEEE 802.15.4 1553 Networks", RFC 4944, September 2007. 1555 11.2. Informative References 1557 [I-D.arkko-core-sleepy-sensors] 1558 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 1559 Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- 1560 sleepy-sensors-01 (work in progress), July 2011. 1562 [I-D.ietf-6lowpan-btle] 1563 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1564 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 1565 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 1566 (work in progress), February 2013. 1568 [I-D.ietf-core-coap] 1569 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1570 "Constrained Application Protocol (CoAP)", draft-ietf- 1571 core-coap-13 (work in progress), December 2012. 1573 [I-D.kivinen-ipsecme-ikev2-minimal] 1574 Kivinen, T., "Minimal IKEv2", draft-kivinen-ipsecme- 1575 ikev2-minimal-01 (work in progress), October 2012. 1577 [I-D.mariager-6lowpan-v6over-dect-ule] 1578 Mariager, P. and J. Petersen, "Transmission of IPv6 1579 Packets over DECT Ultra Low Energy", draft-mariager- 1580 6lowpan-v6over-dect-ule-02 (work in progress), May 2012. 1582 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1583 "Computing the Internet checksum", RFC 1071, September 1584 1988. 1586 [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the 1587 Internet checksum", RFC 1141, January 1990. 1589 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1590 Incremental Update", RFC 1624, May 1994. 1592 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1593 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1594 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1596 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1597 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1598 3748, June 2004. 1600 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 1601 for Transmission Control Protocol (TCP) Specification 1602 Documents", RFC 4614, September 2006. 1604 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1605 Yegin, "Protocol for Carrying Authentication for Network 1606 Access (PANA)", RFC 5191, May 2008. 1608 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1609 Internet", ISBN 9780470747995, 2009. 1611 Author's Address 1613 Carsten Bormann (editor) 1614 Universitaet Bremen TZI 1615 Postfach 330440 1616 Bremen D-28359 1617 Germany 1619 Phone: +49-421-218-63921 1620 Email: cabo@tzi.org