idnits 2.17.1 draft-williams-lwig-api-00.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 'Intended status' indicated for this document; assuming Proposed Standard 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 308, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 311, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 318, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG WG C. Williams 3 Internet-Draft MCSR Labs 4 Expires: September 7, 2012 G. Mulligan 5 Proto6 6 March 6, 2012 8 On Lightweight and Embedded IP Programming Interfaces 9 draft-williams-lwig-api-00.txt 11 Abstract 13 This document takes a look at various aspects of Application 14 Programming Interfaces (APIs) used in embedded sensors and controller 15 applications such as IP Smart Objects and IP based Wireless Sensor 16 Networks. These devices may be interconnected via many different 17 types of media, including 802.15.4 (lowpans), power line control 18 (PLC), RS485, but the common characteristic is that the devices have 19 extremely limited code space and memory space for both the stack and 20 application. Just as there is no one single API for IP networking 21 stacks today (though the "Berkeley sockets" might be considered de- 22 facto standard) there is not likely to be a single standard in the 23 embedded space, but there can be some common understanding about 24 facilities that can and should be provided to the application 25 developer. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 7, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 65 5. API requirements . . . . . . . . . . . . . . . . . . . . . . . 4 66 5.1. Network Parameters . . . . . . . . . . . . . . . . . . . . 4 67 5.2. Sending and Receiving packets . . . . . . . . . . . . . . . 4 68 5.3. Managing network errors . . . . . . . . . . . . . . . . . . 4 69 6. To RTOS or not . . . . . . . . . . . . . . . . . . . . . . . . 4 70 6.1. Using an RTOS . . . . . . . . . . . . . . . . . . . . . . . 4 71 6.2. Providing libraries . . . . . . . . . . . . . . . . . . . . 5 72 7. Low level programming interfaces . . . . . . . . . . . . . . . 5 73 7.1. Berkeley Sockets . . . . . . . . . . . . . . . . . . . . . 5 74 7.1.1. Network management . . . . . . . . . . . . . . . . . . 6 75 7.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 8. High level programming interfaces . . . . . . . . . . . . . . . 6 78 8.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 8.2. Python . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 8.3. Proprietary . . . . . . . . . . . . . . . . . . . . . . . . 6 81 9. Modem type device interface . . . . . . . . . . . . . . . . . . 6 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 7 87 13.2. Informative References . . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 Just as there is no one single Application Programming Interface 93 (API) for IP networking stacks today (though the "Berkeley sockets" 94 might be considered a de-facto standard) there is not likely to be a 95 single standard in the embedded space, but there can be some common 96 understanding about facilities that can and should be provided to the 97 application developer. This document takes a look at various aspects 98 of APIs used in embedded sensor and controller applications and 99 Wireless Sensor Networks, such as IP Smart Objects and Machine to 100 Machine (M2M) applications. 102 Today in some embedded IP applications the IP stack is implemented in 103 a separate external processor that provides a service like a Modem, 104 while the application is run in its own processor. This has provided 105 workable but more costly solutions by requiring two processors. This 106 has the advantage that is separates the application from the network 107 stack and offloads the network processing, but for small low-cost 108 embedded systems the cost of the second processor can be prohibitive. 109 In these cases combining the application and communications 110 processors and providing an application environment in the single 111 processor will provide a lower cost solution. 113 2. Definition Of Terms 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [1]. 119 LowPan Network: 120 It is a wireless (usually) or wired network generally 121 characterized by having constrained nodes. These constraints may 122 be processing, memory or power or any combination 124 3. Assumptions 126 o The 6LowPan host nodes either autoconfigure IPv6 address based on 127 the prefix received in the Router Advertisement, or it uses DHCP 128 for short address assignment. It can receive multiple Router 129 Advertisements and should configure at least one default router as 130 its immediate nexthop. It may configure multiple default routers, 131 but this is implementation specific. The 6LowPan host nodes 132 always send their packets to the default router. If one default 133 router becomes unavailable, it chooses the next available default 134 router or it may restart the ND process. 136 4. Applicability Statement 138 This document aims to guide implementers in choosing appropriate 139 programming interfaces for use in embedded IP devices, such as IP 140 Smart Objects and other highly constrained devices with limited RAM 141 or processing power 143 5. API requirements 145 5.1. Network Parameters 147 Different types of networks will require different types of functions 148 to set-up and manage the network interface. In the case of wireless 149 networks such a IEEE 802.15.4 it is necessary that functions be 150 provided to select the channel and the PANID and possible set or read 151 other IEEE 802.15.4 MAC parameters. 153 5.2. Sending and Receiving packets 155 All APIs must provide some mechanism to send and receive IP packets, 156 otherwise what is the point of a networking stack. Additionaly they 157 may provide higher functions that will compose TCP streams and UDP 158 packets. 160 5.3. Managing network errors 162 All stacks must provide some set of functions to pass network erros 163 to the application. These errors might include local networking 164 errors, such as no IP address set for the interface, no next hop, no 165 route to the destination. These errors might also include remote 166 network errors such as those received via ICMP. 168 6. To RTOS or not 170 One fundamental question for all embedded stack developers is whether 171 they should provide their stack with an RTOS or just a set of library 172 functions. There are pros and cons to each. 174 6.1. Using an RTOS 176 Certainly providing and RTOS does offer a more complete solution, but 177 it tends to contrain the application developer and may add 178 unnecessary overhead (processing, code, memory and power). 180 TinyOS and Contiki are two open source RTOS. Each provides 181 networking functionality and both now offer support for 6lowpan and 182 IPv6. They both have the supporters and detractors. Some developers 183 shy away from TinyOS because they don't want to delve into the world 184 of nesC. Some developers have chosen to not use Contiki because of 185 the design using "protothreads". 187 The advantage that any RTOS provides is that the developer usually 188 does not need to deal with many of the basic timings and can 189 ostensibly write their application as just that, an application, and 190 leave the details to the OS. The disadvantage is that if the 191 application requires either some very specifc timing or possibly some 192 detailed device or network control (sleeping, interrupts, ...) if 193 these are not provided by the RTOS then the application may become 194 more complex than otherwise required. 196 Additionally, as already mentioned, the RTOS may provide unnecessary 197 functionality which could impact code size or memory requirements. 198 The RTOS might also require a change in the design of existing 199 embedded applications in order to be integrated into this 200 environment. 202 6.2. Providing libraries 204 Providing libraries is not a panacea either. While a set of 205 libraries offers the most flexibility (other than writing the 206 complete stack and application), it does put the burden on the 207 programmer to deal with all of the nuances normally taken care of by 208 the OS. As such the programmer must have a better understanding of 209 the specific of the particular microprocessor. 211 7. Low level programming interfaces 213 7.1. Berkeley Sockets 215 A number of companies have implemented embedded networking stacks and 216 provide an interface to the stack (either an RTOS or set of 217 libraries) via a Berkely Socket like set of functions. The major 218 advantage is that Berkely Sockets is widely known, understood and 219 taught. This can greatly speed up the development of networked 220 embedded systems. If the set of library functions it properly 221 written the basic network calls should be able to be used just as if 222 they were a being written on a Unix or Linux system. In the embedded 223 environment it is probably not possible to provide a complete POSIX 224 compliant network interface, but a sufficient subset of functions can 225 be implemented. 227 7.1.1. Network management 229 TBD 231 7.1.2. UDP 233 Sending and receiving UDP packets 235 7.1.3. TCP 237 TBD 239 8. High level programming interfaces 241 8.1. Java 243 The Sun SPOT team built an embedded stack based on the JAVA VM. The 244 stack provided a mechanism to write embedded networking code, 245 including "mobile code", in Java. All of the implementation of the 246 protocols was provided as part of the JVM. The implementation of the 247 JVM required a processor with 8MB of flash and 1MB of RAM. This is 248 larger than would typically be considered an embedded system. 250 8.2. Python 252 At least one company has developed a python engine for small embedded 253 devices. They provide a reduced set of phyton library functions, but 254 they do include the ability to send a receive IP packets. 256 More information TBC (to be completed) 258 8.3. Proprietary 260 TBC 262 9. Modem type device interface 264 Some providers of embedded communications devices have chosen to 265 provide a "closed" external processor that is used to send a receive 266 packets, much like a modem of yesteryears. Some companies have gone 267 as far as to overload the old AT command set to manage the network 268 interface. For example to set the destination address the 269 application processor send the string "ATDT ipaddress/port" as though 270 it was asking the communications process to dial a phone number. 271 Prior to that the application would send other AT commands to define 272 various other parameters such as whether to treat the data as 273 datagrams (UDP) or a stream (TCP). In one case this was overloaded 274 using ATDT (Dial Tone) for TCP and ATDP (Dial Pulse) for UDP and then 275 the application just sends bytes and the outboard processor deals 276 with all the details of managing the connection and sending and 277 receiving data. 279 As already mentioned, while this provides an extremely simple 280 interface and insulates the application developer from any details of 281 the network, it adds cost to the overall system and may not provide 282 an abstraction that allows the system to meet power or timing 283 constraints. 285 10. Security Considerations 287 No known security considerations. 289 11. IANA Considerations 291 There are no IANA considerations for this document. 293 12. Acknowledgements 295 The ideas behind this came from discussion with a number of people 296 including Eric Gnoske, Colin O'Flynn, Kris Pister, David Ewing and 297 folks working in the 6LowPAN WG. 299 13. References 301 13.1. Normative References 303 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 304 Levels", BCP 14, RFC 2119, March 1997. 306 13.2. Informative References 308 [2] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets 309 over IEEE 802.15.4 networks", RFC 4944, September 2007. 311 [3] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 312 Assumptions, Problem Statement and Goals", RFC 4919, 313 August 2007. 315 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), 316 Specification", RFC 2460, December 1998. 318 [5] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 319 October 2003. 321 Authors' Addresses 323 Carl Williams 324 MCSR Labs 325 USA 327 Email: carlw@mcsr-labs.org 329 Geoff Mulligan 330 Proto6 331 USA 333 Email: geoff@proto6.com