[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

LwIP Working Group                                               H. Deng
Internet-Draft                                              China Mobile
Intended status: Informational                                 S. Sakane
Expires: April 27, 2011                                            Cisco
                                                               W. Haddad
                                                                Ericsson
                                                                 N. Kong
                                                                   CNNIC
                                                        October 24, 2010


          Problem Statement of Lightweight IP Protocols Design
                         draft-deng-lwip-ps-01

Abstract

   Since small devices such as sensors are often required to be
   physically small and inexpensive, an implementation of the Internet
   protocols will have to deal with having limited computing resources
   and memory.  This report describes the design and implementation of a
   small TCP/IP stack called lwIP that is small enough to be used in
   minimal systems.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 27, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Deng, et al.             Expires April 27, 2011                 [Page 1]


Internet-Draft                   LwIP PS                    October 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  3
   2.  Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Constraint and Requirements  . . . . . . . . . . . . . . . . .  6
     3.1.  Low Energy Consumption . . . . . . . . . . . . . . . . . .  6
     3.2.  Limited Memory Size  . . . . . . . . . . . . . . . . . . .  6
     3.3.  Various Data Rates . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Rapid Deployment . . . . . . . . . . . . . . . . . . . . .  6
   4.  Current Implementations  . . . . . . . . . . . . . . . . . . .  7
     4.1.  uIP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  LwIP . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  uC/IP  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Blip on TinyOS . . . . . . . . . . . . . . . . . . . . . .  7
     4.5.  TinyTCP  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Lightweight IP Protocols Implementation Issues . . . . . . . .  9
     5.1.  P1: Modularity and Layering  . . . . . . . . . . . . . . .  9
     5.2.  P2: Memory Usage Constraints . . . . . . . . . . . . . . .  9
     5.3.  P3: Inefficient Socket APIs  . . . . . . . . . . . . . . . 10
     5.4.  P4: Protocol Interoperability  . . . . . . . . . . . . . . 10
   6.  Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Lightweight IP Mobility Protocol . . . . . . . . . . . . . 11
     6.2.  Lightweight Service Discovery  . . . . . . . . . . . . . . 11
     6.3.  Lightweight Global Name Services . . . . . . . . . . . . . 11
     6.4.  Device configuration . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17












Deng, et al.             Expires April 27, 2011                 [Page 2]


Internet-Draft                   LwIP PS                    October 2010


1.  Introduction

   Technologies are evolving, but we keep inventing smaller things.  For
   most devices that are commonly used in the Internet of Things
   applications, they are resource constrained.  First, they are built
   on top of the constrained computing platform. e.g. with 8-bit
   microcontrollers and limited RAM and ROM.  Secondly, the connectivity
   between the nodes and the outside network is constrained e.g, some
   networks go down to 20kbps and with limited delivery probability.
   Thirdly, these devices are energy constrained.  They only have
   battery supply and the application users normally do not change their
   battery for long periods of time.

   On the other hand, the applications require more and more resources
   on the the devices.  In home network applications, the small
   monitoring devices are required to send vedio streamings to the
   host's mobile phones, and also in factory monitoring scenarios, the
   requirments for high data rate transmission is emphasized.

   Given the above facts, IP protocols should be designed in as
   lightweight way as possible.  This document summarizes those issues
   met by current practices.  The document also introduces the current
   practices on implementing TCP/IP protocols in a lightweight way, and
   the problems met by implementers.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].





















Deng, et al.             Expires April 27, 2011                 [Page 3]


Internet-Draft                   LwIP PS                    October 2010


2.  Usage Scenario

                ,-''''--''''+                __...._
              ,'             \             ,'       `-.
             /                \           /  Internet  \           v
             |    Wireless    |----------|    Access   |           |
             \    Network    ,'           \           ,'       +---+
              `.           _,              `-._    _,'         |MN3|
                `-..____,,'                    `'''            +---+
                    |                            |
          ********************          ********************
         *                    *        *                    *
         *  In/out-door Net   *        *  In/out-door Net   *
         *      +-------+     *        *    +--------+      *
         *      |Fix-Mob|     *        *    |Fix-Mob |      *
         *      |  GW   |     *        *    |   GW   |      *
         *      +-------+     *        *    +--------+      *
         *          |         *        *         |          *
         *         /|\        *        *        /|\         *
         *zigbee__/ | \_z-wave*        *zigbee_/ | \__z-wave*
         * +--+     |   +--+  *        * +--+    |    +--+  *
         * |a1|     |   |b1|  *        * |a2|    |    |b2|  *
         * +--+     |   +--+  *        * +--+    |    +--+  *
         *          |         *        *         |          *
         *       +--+         *        *       +--+         *
         *       |c1|Bluetooth*        *       |c2|Bluetooth*
          *      +--+        *          *      +--+        *
           ******************            ******************
                          v                     v
                          |                     |
                      +---+                 +---+
                      |MN1|                 |MN2|
                      +---+                 +---+


                          Figure 1: The Scenario

   Currently many applications are built on this scenario.  For example,
   a sensor for the intrusion detection sends messages to the host's
   mobile terminal (MN3) while they away from the house.  The host can
   also send messages via the home gateway to home sensors in order to
   execute some commands, for instance, open the air conditioner before
   going home.  For service discovery, the mobile node should be able to
   discover the service available nearby.  For example, when a MN moves
   to a new environment (moving from its household to its work place),
   it should be able to discover the temperature and humidity
   information service nearby.




Deng, et al.             Expires April 27, 2011                 [Page 4]


Internet-Draft                   LwIP PS                    October 2010


   The connection between the fix-mobile gateway and different types of
   sensors is based on various wireless technologies, for example, IEEE
   802.15.4, Bluetooth, Z-Wave and RFID.  IP protocol, as an adapting
   layer, should run over all these technologies without loosing
   features of communicating, qos, security and etc.  So in order to
   accommodate those different sensing devices, it is highly desirable
   for all the components to talk with IP.  However, both the sensing
   devices and the mobile gateway are built on top of the constrained
   platform.  They are basically constrained in three aspects:

    o Energy Constrained.  Most of the sensors do not have sustained
      power supply.  Some of the gateway nodes also do not have power
      supply.  Among the operations done by these nodes, communication
      is the most energy consuming.  For scenarios like agriculture
      where the GW is most likely sitting somewhere outside in the field
      or floating on water without permanent power connectivity, the
      gateway are mostly out of sustained power supply.  As a
      consequence, network stack implementations should be highly aware
      of these features.

    o Computation Constrained.  The sensor nodes are built upon 8-bit
      MCUs with server kilos of RAM.  The gateway nodes, even if they
      are more powerful than sensors, are not fully capable due to
      economic reasons.  They should maintain the upward connection with
      the global internal as well as the downward connection between the
      sensor nodes.  In many deploy scenarios, those gateway nodes are
      built upon the cellular phone platform (ARM7 or ARM9 with reduced
      computation functionality).  In these scenarios, implementations
      should be aware of the computational capability on the nodes.  And
      if secure computations are involved, implementations will met more
      challenges.

    o Network Constrained.  The lower layer connection between the
      mobile gateway and the sensors is running at low data rate.  For
      example, IEEE 802.15.4 provides over-the-air rates from 20kbps to
      100kbps at 868/915 MHz.  Implementations should be aware of the
      lower layer capability in order to be compliant.














Deng, et al.             Expires April 27, 2011                 [Page 5]


Internet-Draft                   LwIP PS                    October 2010


3.  Constraint and Requirements

3.1.  Low Energy Consumption

   This requirement is derived from several reasons.

    o  it is necessary to use the devices at long time. the device is
       sometimes driven with a non-rechargeable and non-replaceable
       battery.

    o  it is necessary to use the devices in the explosion atomosphere
       of the process automation.

    o  in the human sensing, in particular, the inside of the human body
       sensing, the battery is very low power.

    o  essentially, in the world wide movement, minimizing energy
       consumption must be considered.

3.2.  Limited Memory Size

   The sensors are running at very constrained platforms with 8-bit
   micro-controllers and several kilos RAM.  Even the fixed/mobile
   gateways are not fully capable devices; they are built on cheap
   chipsets for economic reasons.  It is required for applications to be
   deployed and developed above these constrained platforms.

3.3.  Various Data Rates

   It depends on the application requirement, video, audio streaming, or
   periodical sensing.  The media type restricts the data rate.
   Actually, the technology develops the rate of the media.  However, we
   have to consider about it for practical.

3.4.  Rapid Deployment

   Meanwhile, there are numerous kinds of mobile terminals with
   heterogeneous platforms.  It is difficult for developers to design
   universal expansion hardware to help mobile terminals access the
   sensor networks.  Consequently, it is desirable to see some rapid
   deployment techniques to faciliate the fix-mobile gateway accessing
   the sensor network without affecting the mobile terminal platforms
   too much. uSD [usd] is such a practice.








Deng, et al.             Expires April 27, 2011                 [Page 6]


Internet-Draft                   LwIP PS                    October 2010


4.  Current Implementations

4.1.  uIP

   uIP is an implementation of the TCP/IP protocol stack intended for
   small 8-bit and 16-bit microcontrollers.  It is completely RFC1122
   compliant but has some limitations.  For instance, a retransmit is
   managed by the stack, but the data that needs to be retransmitted is
   requested from the user application.

   uIP can be used together with Contiki, a very small OS which supports
   dynamic application download and a gui using VNC.  The uIP stack uses
   less then 10kB ROM and 2kB RAM and Contiki can easily fit in 100kB
   ROM and 10kB RAM.  You can use it any way you want as long as you
   leave a copy of the copyright notice in the source and/or
   documentation. uIP can be accessed via http://www.sics.se/~adam/uip/

4.2.  LwIP

   LwIP is a TCP/IP implementation designed for small code size and
   efficient memory usage.  It is still widely used, and implemented.
   And is designed to use with or without an operating system. lwIP uses
   around 40kB of RAM and 30kB ROM and you can use it any way you want
   as long as you leave a copy of the copyright notice in the source
   and/or documentation.  LwIP can be found via
   http://www.sics.se/~adam/lwip/

4.3.  uC/IP

   uC/IP is a TCP/IP stack developed for microcontrollers and embedded
   systems but is not often used.  It based on the BSD TCP/IP
   implementations and is still a bit large compared to other
   implementations. uC/IP carries the BSD license so you can freely use
   it as long as you leave a copy of the copyright notice in the source
   and/or documentation. uC/IP can be found via
   http://ucip.sourceforge.net/

4.4.  Blip on TinyOS

   BLIP, the Berkeley Low-power IP stack, is an implementation in tinyos
   [tinyos] of a number of IP-based protocols.  Using blip/tinyos, you
   will be able to form multi-hop IP networks consisting of different
   motes communicating over shared protocols.  It has been tested on
   micaz, telosb, and epic platforms.  It is not based on tinyos' active
   message layer, and the blip router is only supported on Linux, as of
   2.1.1.

   BLIP can be found via



Deng, et al.             Expires April 27, 2011                 [Page 7]


Internet-Draft                   LwIP PS                    October 2010


   http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip.

4.5.  TinyTCP

   TinyTCP is a small implementation of the TCP and IP protocols,
   suitable for burning into ROM.  A timer and an ethernet board are
   assumed.  The implementation is based on busy-waiting, but the
   tcp_handler procedure could easily be integrated into an interrupt
   driven scheme.  The TCP does not implement urgent pointers (easy to
   add), and discards segments that are received out of order.  It
   ignores the received window and always offers a fixed window size on
   input (i.e., it is not flow controlled).

   TinyTCP can be found via
   http://www.unusualresearch.com/tinytcp/tinytcp.htm




































Deng, et al.             Expires April 27, 2011                 [Page 8]


Internet-Draft                   LwIP PS                    October 2010


5.  Lightweight IP Protocols Implementation Issues

5.1.  P1: Modularity and Layering

   In many TCP/IP implementations, the layered protocol design has
   served as a guide.  Each protocol shall be implemented separately
   from the other.  However, implementing the protocols in a strictly
   layered way sometimes leads to a situiation where the communication
   overhead between the protocol layers degrades the overall performance
   [RFC0817].  To tackle this problem, care must be taken so that only
   the important information is shared among layers.

   The other fact is that the operation systems used in the constrained
   systems most often do not maintain a strict protection barrier
   between the kernel and application processes, such as TinyOS and
   Contiki.  This offers an opportunity for more relaxed communication
   between application and the lower layer protocols via shared memory,
   so that the internet-working stack can use the memory more
   efficiently.

   So in order to improve performance in terms of processing speed and
   memory usage, implementors should in many situations violate the
   layering assumptions.  For example, when verifying the checksum of an
   incoming TCP segment and when demultiplexing a segment, passing the
   source and destinations addresses to TCP via funtion calls will
   inevitably result into more memory consumption.  In this case, making
   the TCP module aware of the structure of the IP header is more
   efficient althout it violates certain layering and modularity
   assumptions.

5.2.  P2: Memory Usage Constraints

   Constrained devices with several kilos of memory cannot survice
   dynamic memeory allocation schemes.  Most used MTU for the IP
   networks are 1500 bytes or bigger.  One full size IPv4/IPv6 packet
   scales to more than a thousand bytes memory when using dynamic
   allocation.  How to holding the incoming and outgoing packets to
   reduce the memory usage is a challenging question then.

   For example, uIP [uip] uses preallocated buffers, in which a fixed
   table is used to hold the connection state while a global buffer is
   used to hold all the incoming and outgoing packets.  Moreover, uIP
   also implements zero-copy mechanisms over the packet buffer to
   further reduce memory usage and minimize the data transfers between
   the TCP/IP stack and the application program.  As a result, the size
   of the global packet buffer is determined by a configuration option
   at compile time, which guarantees that the buffer is large enough to
   accommodate a packet of the maximum allowed size.  Nevertheless, due



Deng, et al.             Expires April 27, 2011                 [Page 9]


Internet-Draft                   LwIP PS                    October 2010


   to the implemented zero-copy mechanisms the application program must
   be carefully designed and pay special attention to all the packets
   arriving from the network to avoid packet loss, which occurs whenever
   the network device buffers become full.

5.3.  P3: Inefficient Socket APIs

   The BSD socket API requires the support of a multitasking system
   which imposes a significant overhead due to the need for task
   management, context switching and allocation of stack space.  This is
   overbearing on many constrained platforms.

   As a result, it is desirable to have a reduced event driven API with
   only the minimal and necessary functions is used to implement a
   TCP/IP stack optimized for small 8 and 16-bit systems.  Using this
   approach the application program is only invoked in response to
   specific events, such as data arriving from a connection or an
   incoming connection request, which allows achieving minimum response
   times even in low-end systems

5.4.  P4: Protocol Interoperability

   Many implementations on constrained devices have implemeted different
   sets of features of the IP protocols.  For example, some do not
   handle IP fragmentation and reassembly, and some do not handle IP
   options.  Due to the lack of implementation guidelines and protocol
   implementation profiles, the interoperability between different
   implementations potentially is problem.























Deng, et al.             Expires April 27, 2011                [Page 10]


Internet-Draft                   LwIP PS                    October 2010


6.  Other Issues

6.1.  Lightweight IP Mobility Protocol

   Mobility patterns for the small devices is different from what's been
   investigated in typical Internet IP mobility.  IP mobility solutions,
   such as MIPv4/v6, DSMIPv6 or PMIPv6, normally have incurred overhead
   through the use of heartbeat signalings, IP tunnels and security
   associations.  On small and constrained devices, they may not
   surrive, heartbeat signalings waking the device up too much for
   energy consumption. for example, Mobile IPv6 is too heavy in terms of
   security requirements and signaling exchange to be implemented on
   mobile GWs.

6.2.  Lightweight Service Discovery

   There are lots of constrained devices in the networks.  To find a
   service of an application, a service discovery is required.  There
   are several kind of the service discovery protocol like DNS-SD, SSDP,
   or XMPP.  These protocols were not designed to assume running on the
   constrained devices.  For example, XMPP is based on XML.  It is
   indeed scalable to its contants.  But, it is likely not "thing-
   friendly".  Each of them are necessary to be considered whether it is
   suitable or not.  Further investigation is needed.

6.3.  Lightweight Global Name Services

   Global name services such as DNS (Domain Name System) [RFC1034] have
   already been one of the most important infrastructures of the
   Internet nowadays.  For example, DNS is an indispensable system of
   the Internet used for translating the "human-friendly" host names of
   computers on a TCP/IP network into their corresponding "machine-
   friendly" IP addresses.  In general, DNS also stores other types of
   information, such as the list of mail servers that accept email for a
   given Internet domain.  By providing a worldwide, distributed name
   service, DNS is an essential component of the functionality of the
   Internet.

   Similarly, global name services will also be one of essential and key
   elements in constrained networks, which can be used for translating
   the "thing-friendly" names of constrained devices or RFID tags on a
   lightweight TCP/IP network into their corresponding "machine-
   friendly" addresses or other related information of another
   constrained network.  The applications or devices on a constrained
   network can easily communicate with other devices on the same or any
   other constrained network with the name of the constrained device by
   a global name service, without considering whether the address of the
   targeted constrained device on a constrained network has been changed



Deng, et al.             Expires April 27, 2011                [Page 11]


Internet-Draft                   LwIP PS                    October 2010


   or not.

   To fulfill the aforementioned objective, a lightweight global name
   service based on the LWIP protocol needs to be researched.  The
   efficiency of this kind of service is supposed to be the most
   important issue to be studied in future.

6.4.  Device configuration

   There are several type of devices for several purposes, and several
   applications running on the devices in the scenarios.  There are some
   devices which has a monitor and a keyboard to monitor and to control
   the networks for administrating.  But, most devices like a sensor, or
   a actuator do not have enough space to have such interface.  It means
   there is no configuration interface of the device.  The constrained
   device sometimes have to be configuared via an flash memory, or
   another interface like USB.  However, it is difficult to set up
   handreds of devices in the networks.  Furthermore, some types of
   devices like a temperature sesor do not have a space for it.  In this
   scenario, it is recommended to configure the devices via the network.
   And, special messaging and special format are not scalable.  We
   should have to consider the method to configure the device via a
   similar way.




























Deng, et al.             Expires April 27, 2011                [Page 12]


Internet-Draft                   LwIP PS                    October 2010


7.  Security Considerations

   TBD.
















































Deng, et al.             Expires April 27, 2011                [Page 13]


Internet-Draft                   LwIP PS                    October 2010


8.  Acknowledgement

   TBD.
















































Deng, et al.             Expires April 27, 2011                [Page 14]


Internet-Draft                   LwIP PS                    October 2010


9.  IANA Considerations

   This document does not require any IANA actions.
















































Deng, et al.             Expires April 27, 2011                [Page 15]


Internet-Draft                   LwIP PS                    October 2010


10.  Normative References

   [I-D.moskowitz-hip-rg-dex]
              Moskowitz, R., "HIP Diet EXchange (DEX)",
              draft-moskowitz-hip-rg-dex-02 (work in progress),
              July 2010.

   [RFC0813]  Clark, D., "Window and Acknowledgement Strategy in TCP",
              RFC 813, July 1982.

   [RFC0817]  Clark, D., "Modularity and efficiency in protocol
              implementation", RFC 817, July 1982.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [tinyos]   "Tiny Operation System on Mica Series Sensors",
              <www.tinyos.net>.

   [uip]      "Full TCP/IP for 8-bit Architectures",
              <http://www.sics.se/~adam/uip/index.php/Main_Page>.

   [usd]      Canfeng Chen, "uSD: an SD-based Mobile Gateway to Wireless
              Sensor Network".
























Deng, et al.             Expires April 27, 2011                [Page 16]


Internet-Draft                   LwIP PS                    October 2010


Authors' Addresses

   Hui Deng
   China Mobile
   Unit2, 28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: denghui@chinamobile.com


   Shoichi Sakane
   Cisco
   2-1-1 Nishi-Shinjuku, Shinjuku-ku
   Tokyo 163-0409
   Japan

   Email: ssakane@cisco.com


   Wassim Michel Haddad
   Ericsson
   300 Holger Dr
   San Jose, CA  95134
   US

   Phone: +1 646 256 2030
   Email: Wassim.Haddad@ericsson.com


   Ning Kong
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3147
   Email: nkong@cnnic.cn













Deng, et al.             Expires April 27, 2011                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/