idnits 2.17.1 draft-deng-lwip-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 has text resembling RFC 2119 boilerplate text. -- The document date (October 24, 2010) is 4905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.moskowitz-hip-rg-dex' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC0813' is defined on line 480, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-rg-dex-02 ** Obsolete normative reference: RFC 813 (Obsoleted by RFC 7805) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LwIP Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Informational S. Sakane 5 Expires: April 27, 2011 Cisco 6 W. Haddad 7 Ericsson 8 N. Kong 9 CNNIC 10 October 24, 2010 12 Problem Statement of Lightweight IP Protocols Design 13 draft-deng-lwip-ps-01 15 Abstract 17 Since small devices such as sensors are often required to be 18 physically small and inexpensive, an implementation of the Internet 19 protocols will have to deal with having limited computing resources 20 and memory. This report describes the design and implementation of a 21 small TCP/IP stack called lwIP that is small enough to be used in 22 minimal systems. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 27, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Conventions used in this document . . . . . . . . . . . . 3 60 2. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Constraint and Requirements . . . . . . . . . . . . . . . . . 6 62 3.1. Low Energy Consumption . . . . . . . . . . . . . . . . . . 6 63 3.2. Limited Memory Size . . . . . . . . . . . . . . . . . . . 6 64 3.3. Various Data Rates . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Rapid Deployment . . . . . . . . . . . . . . . . . . . . . 6 66 4. Current Implementations . . . . . . . . . . . . . . . . . . . 7 67 4.1. uIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. LwIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. uC/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.4. Blip on TinyOS . . . . . . . . . . . . . . . . . . . . . . 7 71 4.5. TinyTCP . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Lightweight IP Protocols Implementation Issues . . . . . . . . 9 73 5.1. P1: Modularity and Layering . . . . . . . . . . . . . . . 9 74 5.2. P2: Memory Usage Constraints . . . . . . . . . . . . . . . 9 75 5.3. P3: Inefficient Socket APIs . . . . . . . . . . . . . . . 10 76 5.4. P4: Protocol Interoperability . . . . . . . . . . . . . . 10 77 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Lightweight IP Mobility Protocol . . . . . . . . . . . . . 11 79 6.2. Lightweight Service Discovery . . . . . . . . . . . . . . 11 80 6.3. Lightweight Global Name Services . . . . . . . . . . . . . 11 81 6.4. Device configuration . . . . . . . . . . . . . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 Technologies are evolving, but we keep inventing smaller things. For 91 most devices that are commonly used in the Internet of Things 92 applications, they are resource constrained. First, they are built 93 on top of the constrained computing platform. e.g. with 8-bit 94 microcontrollers and limited RAM and ROM. Secondly, the connectivity 95 between the nodes and the outside network is constrained e.g, some 96 networks go down to 20kbps and with limited delivery probability. 97 Thirdly, these devices are energy constrained. They only have 98 battery supply and the application users normally do not change their 99 battery for long periods of time. 101 On the other hand, the applications require more and more resources 102 on the the devices. In home network applications, the small 103 monitoring devices are required to send vedio streamings to the 104 host's mobile phones, and also in factory monitoring scenarios, the 105 requirments for high data rate transmission is emphasized. 107 Given the above facts, IP protocols should be designed in as 108 lightweight way as possible. This document summarizes those issues 109 met by current practices. The document also introduces the current 110 practices on implementing TCP/IP protocols in a lightweight way, and 111 the problems met by implementers. 113 1.1. Conventions used in this document 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 [RFC2119]. 119 2. Usage Scenario 121 ,-''''--''''+ __...._ 122 ,' \ ,' `-. 123 / \ / Internet \ v 124 | Wireless |----------| Access | | 125 \ Network ,' \ ,' +---+ 126 `. _, `-._ _,' |MN3| 127 `-..____,,' `''' +---+ 128 | | 129 ******************** ******************** 130 * * * * 131 * In/out-door Net * * In/out-door Net * 132 * +-------+ * * +--------+ * 133 * |Fix-Mob| * * |Fix-Mob | * 134 * | GW | * * | GW | * 135 * +-------+ * * +--------+ * 136 * | * * | * 137 * /|\ * * /|\ * 138 *zigbee__/ | \_z-wave* *zigbee_/ | \__z-wave* 139 * +--+ | +--+ * * +--+ | +--+ * 140 * |a1| | |b1| * * |a2| | |b2| * 141 * +--+ | +--+ * * +--+ | +--+ * 142 * | * * | * 143 * +--+ * * +--+ * 144 * |c1|Bluetooth* * |c2|Bluetooth* 145 * +--+ * * +--+ * 146 ****************** ****************** 147 v v 148 | | 149 +---+ +---+ 150 |MN1| |MN2| 151 +---+ +---+ 153 Figure 1: The Scenario 155 Currently many applications are built on this scenario. For example, 156 a sensor for the intrusion detection sends messages to the host's 157 mobile terminal (MN3) while they away from the house. The host can 158 also send messages via the home gateway to home sensors in order to 159 execute some commands, for instance, open the air conditioner before 160 going home. For service discovery, the mobile node should be able to 161 discover the service available nearby. For example, when a MN moves 162 to a new environment (moving from its household to its work place), 163 it should be able to discover the temperature and humidity 164 information service nearby. 166 The connection between the fix-mobile gateway and different types of 167 sensors is based on various wireless technologies, for example, IEEE 168 802.15.4, Bluetooth, Z-Wave and RFID. IP protocol, as an adapting 169 layer, should run over all these technologies without loosing 170 features of communicating, qos, security and etc. So in order to 171 accommodate those different sensing devices, it is highly desirable 172 for all the components to talk with IP. However, both the sensing 173 devices and the mobile gateway are built on top of the constrained 174 platform. They are basically constrained in three aspects: 176 o Energy Constrained. Most of the sensors do not have sustained 177 power supply. Some of the gateway nodes also do not have power 178 supply. Among the operations done by these nodes, communication 179 is the most energy consuming. For scenarios like agriculture 180 where the GW is most likely sitting somewhere outside in the field 181 or floating on water without permanent power connectivity, the 182 gateway are mostly out of sustained power supply. As a 183 consequence, network stack implementations should be highly aware 184 of these features. 186 o Computation Constrained. The sensor nodes are built upon 8-bit 187 MCUs with server kilos of RAM. The gateway nodes, even if they 188 are more powerful than sensors, are not fully capable due to 189 economic reasons. They should maintain the upward connection with 190 the global internal as well as the downward connection between the 191 sensor nodes. In many deploy scenarios, those gateway nodes are 192 built upon the cellular phone platform (ARM7 or ARM9 with reduced 193 computation functionality). In these scenarios, implementations 194 should be aware of the computational capability on the nodes. And 195 if secure computations are involved, implementations will met more 196 challenges. 198 o Network Constrained. The lower layer connection between the 199 mobile gateway and the sensors is running at low data rate. For 200 example, IEEE 802.15.4 provides over-the-air rates from 20kbps to 201 100kbps at 868/915 MHz. Implementations should be aware of the 202 lower layer capability in order to be compliant. 204 3. Constraint and Requirements 206 3.1. Low Energy Consumption 208 This requirement is derived from several reasons. 210 o it is necessary to use the devices at long time. the device is 211 sometimes driven with a non-rechargeable and non-replaceable 212 battery. 214 o it is necessary to use the devices in the explosion atomosphere 215 of the process automation. 217 o in the human sensing, in particular, the inside of the human body 218 sensing, the battery is very low power. 220 o essentially, in the world wide movement, minimizing energy 221 consumption must be considered. 223 3.2. Limited Memory Size 225 The sensors are running at very constrained platforms with 8-bit 226 micro-controllers and several kilos RAM. Even the fixed/mobile 227 gateways are not fully capable devices; they are built on cheap 228 chipsets for economic reasons. It is required for applications to be 229 deployed and developed above these constrained platforms. 231 3.3. Various Data Rates 233 It depends on the application requirement, video, audio streaming, or 234 periodical sensing. The media type restricts the data rate. 235 Actually, the technology develops the rate of the media. However, we 236 have to consider about it for practical. 238 3.4. Rapid Deployment 240 Meanwhile, there are numerous kinds of mobile terminals with 241 heterogeneous platforms. It is difficult for developers to design 242 universal expansion hardware to help mobile terminals access the 243 sensor networks. Consequently, it is desirable to see some rapid 244 deployment techniques to faciliate the fix-mobile gateway accessing 245 the sensor network without affecting the mobile terminal platforms 246 too much. uSD [usd] is such a practice. 248 4. Current Implementations 250 4.1. uIP 252 uIP is an implementation of the TCP/IP protocol stack intended for 253 small 8-bit and 16-bit microcontrollers. It is completely RFC1122 254 compliant but has some limitations. For instance, a retransmit is 255 managed by the stack, but the data that needs to be retransmitted is 256 requested from the user application. 258 uIP can be used together with Contiki, a very small OS which supports 259 dynamic application download and a gui using VNC. The uIP stack uses 260 less then 10kB ROM and 2kB RAM and Contiki can easily fit in 100kB 261 ROM and 10kB RAM. You can use it any way you want as long as you 262 leave a copy of the copyright notice in the source and/or 263 documentation. uIP can be accessed via http://www.sics.se/~adam/uip/ 265 4.2. LwIP 267 LwIP is a TCP/IP implementation designed for small code size and 268 efficient memory usage. It is still widely used, and implemented. 269 And is designed to use with or without an operating system. lwIP uses 270 around 40kB of RAM and 30kB ROM and you can use it any way you want 271 as long as you leave a copy of the copyright notice in the source 272 and/or documentation. LwIP can be found via 273 http://www.sics.se/~adam/lwip/ 275 4.3. uC/IP 277 uC/IP is a TCP/IP stack developed for microcontrollers and embedded 278 systems but is not often used. It based on the BSD TCP/IP 279 implementations and is still a bit large compared to other 280 implementations. uC/IP carries the BSD license so you can freely use 281 it as long as you leave a copy of the copyright notice in the source 282 and/or documentation. uC/IP can be found via 283 http://ucip.sourceforge.net/ 285 4.4. Blip on TinyOS 287 BLIP, the Berkeley Low-power IP stack, is an implementation in tinyos 288 [tinyos] of a number of IP-based protocols. Using blip/tinyos, you 289 will be able to form multi-hop IP networks consisting of different 290 motes communicating over shared protocols. It has been tested on 291 micaz, telosb, and epic platforms. It is not based on tinyos' active 292 message layer, and the blip router is only supported on Linux, as of 293 2.1.1. 295 BLIP can be found via 296 http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip. 298 4.5. TinyTCP 300 TinyTCP is a small implementation of the TCP and IP protocols, 301 suitable for burning into ROM. A timer and an ethernet board are 302 assumed. The implementation is based on busy-waiting, but the 303 tcp_handler procedure could easily be integrated into an interrupt 304 driven scheme. The TCP does not implement urgent pointers (easy to 305 add), and discards segments that are received out of order. It 306 ignores the received window and always offers a fixed window size on 307 input (i.e., it is not flow controlled). 309 TinyTCP can be found via 310 http://www.unusualresearch.com/tinytcp/tinytcp.htm 312 5. Lightweight IP Protocols Implementation Issues 314 5.1. P1: Modularity and Layering 316 In many TCP/IP implementations, the layered protocol design has 317 served as a guide. Each protocol shall be implemented separately 318 from the other. However, implementing the protocols in a strictly 319 layered way sometimes leads to a situiation where the communication 320 overhead between the protocol layers degrades the overall performance 321 [RFC0817]. To tackle this problem, care must be taken so that only 322 the important information is shared among layers. 324 The other fact is that the operation systems used in the constrained 325 systems most often do not maintain a strict protection barrier 326 between the kernel and application processes, such as TinyOS and 327 Contiki. This offers an opportunity for more relaxed communication 328 between application and the lower layer protocols via shared memory, 329 so that the internet-working stack can use the memory more 330 efficiently. 332 So in order to improve performance in terms of processing speed and 333 memory usage, implementors should in many situations violate the 334 layering assumptions. For example, when verifying the checksum of an 335 incoming TCP segment and when demultiplexing a segment, passing the 336 source and destinations addresses to TCP via funtion calls will 337 inevitably result into more memory consumption. In this case, making 338 the TCP module aware of the structure of the IP header is more 339 efficient althout it violates certain layering and modularity 340 assumptions. 342 5.2. P2: Memory Usage Constraints 344 Constrained devices with several kilos of memory cannot survice 345 dynamic memeory allocation schemes. Most used MTU for the IP 346 networks are 1500 bytes or bigger. One full size IPv4/IPv6 packet 347 scales to more than a thousand bytes memory when using dynamic 348 allocation. How to holding the incoming and outgoing packets to 349 reduce the memory usage is a challenging question then. 351 For example, uIP [uip] uses preallocated buffers, in which a fixed 352 table is used to hold the connection state while a global buffer is 353 used to hold all the incoming and outgoing packets. Moreover, uIP 354 also implements zero-copy mechanisms over the packet buffer to 355 further reduce memory usage and minimize the data transfers between 356 the TCP/IP stack and the application program. As a result, the size 357 of the global packet buffer is determined by a configuration option 358 at compile time, which guarantees that the buffer is large enough to 359 accommodate a packet of the maximum allowed size. Nevertheless, due 360 to the implemented zero-copy mechanisms the application program must 361 be carefully designed and pay special attention to all the packets 362 arriving from the network to avoid packet loss, which occurs whenever 363 the network device buffers become full. 365 5.3. P3: Inefficient Socket APIs 367 The BSD socket API requires the support of a multitasking system 368 which imposes a significant overhead due to the need for task 369 management, context switching and allocation of stack space. This is 370 overbearing on many constrained platforms. 372 As a result, it is desirable to have a reduced event driven API with 373 only the minimal and necessary functions is used to implement a 374 TCP/IP stack optimized for small 8 and 16-bit systems. Using this 375 approach the application program is only invoked in response to 376 specific events, such as data arriving from a connection or an 377 incoming connection request, which allows achieving minimum response 378 times even in low-end systems 380 5.4. P4: Protocol Interoperability 382 Many implementations on constrained devices have implemeted different 383 sets of features of the IP protocols. For example, some do not 384 handle IP fragmentation and reassembly, and some do not handle IP 385 options. Due to the lack of implementation guidelines and protocol 386 implementation profiles, the interoperability between different 387 implementations potentially is problem. 389 6. Other Issues 391 6.1. Lightweight IP Mobility Protocol 393 Mobility patterns for the small devices is different from what's been 394 investigated in typical Internet IP mobility. IP mobility solutions, 395 such as MIPv4/v6, DSMIPv6 or PMIPv6, normally have incurred overhead 396 through the use of heartbeat signalings, IP tunnels and security 397 associations. On small and constrained devices, they may not 398 surrive, heartbeat signalings waking the device up too much for 399 energy consumption. for example, Mobile IPv6 is too heavy in terms of 400 security requirements and signaling exchange to be implemented on 401 mobile GWs. 403 6.2. Lightweight Service Discovery 405 There are lots of constrained devices in the networks. To find a 406 service of an application, a service discovery is required. There 407 are several kind of the service discovery protocol like DNS-SD, SSDP, 408 or XMPP. These protocols were not designed to assume running on the 409 constrained devices. For example, XMPP is based on XML. It is 410 indeed scalable to its contants. But, it is likely not "thing- 411 friendly". Each of them are necessary to be considered whether it is 412 suitable or not. Further investigation is needed. 414 6.3. Lightweight Global Name Services 416 Global name services such as DNS (Domain Name System) [RFC1034] have 417 already been one of the most important infrastructures of the 418 Internet nowadays. For example, DNS is an indispensable system of 419 the Internet used for translating the "human-friendly" host names of 420 computers on a TCP/IP network into their corresponding "machine- 421 friendly" IP addresses. In general, DNS also stores other types of 422 information, such as the list of mail servers that accept email for a 423 given Internet domain. By providing a worldwide, distributed name 424 service, DNS is an essential component of the functionality of the 425 Internet. 427 Similarly, global name services will also be one of essential and key 428 elements in constrained networks, which can be used for translating 429 the "thing-friendly" names of constrained devices or RFID tags on a 430 lightweight TCP/IP network into their corresponding "machine- 431 friendly" addresses or other related information of another 432 constrained network. The applications or devices on a constrained 433 network can easily communicate with other devices on the same or any 434 other constrained network with the name of the constrained device by 435 a global name service, without considering whether the address of the 436 targeted constrained device on a constrained network has been changed 437 or not. 439 To fulfill the aforementioned objective, a lightweight global name 440 service based on the LWIP protocol needs to be researched. The 441 efficiency of this kind of service is supposed to be the most 442 important issue to be studied in future. 444 6.4. Device configuration 446 There are several type of devices for several purposes, and several 447 applications running on the devices in the scenarios. There are some 448 devices which has a monitor and a keyboard to monitor and to control 449 the networks for administrating. But, most devices like a sensor, or 450 a actuator do not have enough space to have such interface. It means 451 there is no configuration interface of the device. The constrained 452 device sometimes have to be configuared via an flash memory, or 453 another interface like USB. However, it is difficult to set up 454 handreds of devices in the networks. Furthermore, some types of 455 devices like a temperature sesor do not have a space for it. In this 456 scenario, it is recommended to configure the devices via the network. 457 And, special messaging and special format are not scalable. We 458 should have to consider the method to configure the device via a 459 similar way. 461 7. Security Considerations 463 TBD. 465 8. Acknowledgement 467 TBD. 469 9. IANA Considerations 471 This document does not require any IANA actions. 473 10. Normative References 475 [I-D.moskowitz-hip-rg-dex] 476 Moskowitz, R., "HIP Diet EXchange (DEX)", 477 draft-moskowitz-hip-rg-dex-02 (work in progress), 478 July 2010. 480 [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", 481 RFC 813, July 1982. 483 [RFC0817] Clark, D., "Modularity and efficiency in protocol 484 implementation", RFC 817, July 1982. 486 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 487 STD 13, RFC 1034, November 1987. 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [tinyos] "Tiny Operation System on Mica Series Sensors", 493 . 495 [uip] "Full TCP/IP for 8-bit Architectures", 496 . 498 [usd] Canfeng Chen, "uSD: an SD-based Mobile Gateway to Wireless 499 Sensor Network". 501 Authors' Addresses 503 Hui Deng 504 China Mobile 505 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 506 Beijing 100053 507 China 509 Email: denghui@chinamobile.com 511 Shoichi Sakane 512 Cisco 513 2-1-1 Nishi-Shinjuku, Shinjuku-ku 514 Tokyo 163-0409 515 Japan 517 Email: ssakane@cisco.com 519 Wassim Michel Haddad 520 Ericsson 521 300 Holger Dr 522 San Jose, CA 95134 523 US 525 Phone: +1 646 256 2030 526 Email: Wassim.Haddad@ericsson.com 528 Ning Kong 529 CNNIC 530 4 South 4th Street,Zhongguancun,Haidian District 531 Beijing, Beijing 100190 532 China 534 Phone: +86 10 5881 3147 535 Email: nkong@cnnic.cn