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

Versions: 00 01

Network Working Group                                            Y. Hong
Internet-Draft                                                      ETRI
Intended status: Informational                                   J. Youn
Expires: January 16, 2014                                 DONG-EUI Univ.
                                                           July 15, 2013


   Problem statement and Use cases of Sleepy node in Constrained node
                                networks
            draft-hong-lwig-sleepynode-problem-statement-00

Abstract

   This document describes the use cases of communication considering
   sleepy nodes and the problems of connecting to sleepy nodes in
   constrained node networks.  The use cases of communications between
   sleepy nodes and non-sleepy nodes are classified by the end-to-end
   communication and the network topology.  The adopt of power saving in
   constrained nodes raises compelling problems in network layer/
   transport/application layer.  In this document, problems of each
   layer in a sleepy node are described.

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 January 16, 2014.

Copyright Notice

   Copyright (c) 2013 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
   publication of this document.  Please review these documents



Hong & Youn             Expires January 16, 2014                [Page 1]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Related Work and Background . . . . . . . . . . . . . . . . .   3
   4.  Use Cases of communication of a sleepy node . . . . . . . . .   4
     4.1.  Communication between a sleepy node and a non-sleepy node   4
     4.2.  Communication between sleepy nodes  . . . . . . . . . . .   5
     4.3.  Communication across routers  . . . . . . . . . . . . . .   5
     4.4.  Communication within a router . . . . . . . . . . . . . .   6
     4.5.  Communication in ad-hoc network . . . . . . . . . . . . .   6
   5.  Problem statement of communication of a sleepy node . . . . .   6
     5.1.  Problems of a sleepy node in Network layer  . . . . . . .   6
     5.2.  Problems of a sleepy node in Transport layer  . . . . . .   7
     5.3.  Problems of a sleepy node in Application layer  . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Until now, it seems that the Internet protocol (e.g., TCP/IP protocol
   suite) is not directly related to power management, because it is
   assumed that network nodes are always connected to main-power.  Even
   though, the network nodes are moving and the network nodes are not
   connected to main power (e.g., the network nodes may use battery or
   energy harvesting), the power management has been focused on PHY/MAC
   layer.  Recently, as constrained nodes in constrained node networks
   become connected to the Internet, it is required to consider power
   management in Internet protocol in the IETF scape.

   The goals for power management may be different by the conditions of
   device and environment.  The general strategies for power management
   of various conditions are depicted as always-on, always-off, and low-
   power [I-D.arkko-lwig-cellular].  A constrained node, creating
   constrained node networks, may occasionally go into sleep mode
   according to strategies of using power for communication
   [I-D.ietf-lwig-terminology].  In [I-D.ietf-lwig-terminology], a
   device is divided into four classes according to energy limitation of



Hong & Youn             Expires January 16, 2014                [Page 2]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   a device.  Here, the constrained nodes classed such as class E1 and
   E2 in classes of energy limitation may occasionally go into sleepy
   mode.  Thus, in constrained node networks, there can exist the end-
   to-end communications between a sleep mode node and a non-sleep mode
   node.

   Some Internet protocols in the IEFT scape assume that the state of a
   node is always-on mode, such as a non-sleep mode, of a node.  While
   in constrained node networks the state of a node can be divided into
   a non-sleep mode and sleep mode.  Thus, at end-to-end communication
   perspective, a sleepy node make various problems when Neighbor
   Discovery is operated and message or data is transmitted between
   constrained nodes through Internet protocols in the IEFT.  In
   particular, because the operation of Neighbor Discovery is done with
   the assumption that the network node is always-on connected, the
   operation of Neighbor Discovery of sleepy node may make operational
   problem.  And, sleepy node may affect the performance negatively at
   application layer and transport layer.  First at all, in end-to-end
   communication perspective, sleepy node can generate unnecessary
   message/data transmission at application layer and transport layer.
   In other word, without the state information of a destination node, a
   source node transmits the message or data to a destination node that
   goes into sleep mode.  This point will affect a constrained node with
   the limit power negatively in terms of energy efficient of a
   constrained node.

2.  Conventions and Terminology

   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].

3.  Related Work and Background

   Power saving in wireless networks is mainly accomplished in PHY/MAC
   layer.  The basic idea of power saving in PHY/MAC layer is to
   minimize the time of transmission/receipt.  In IEEE 802.11 WLAN, the
   feature of power saving is Power Save Mode (PSM) that is available
   for nodes existing in an infrastructure based IEEE 802.11 WLAN.  PSM
   is based on a synchronous sleep scheduling policy, in which wireless
   nodes are able to alternate between an active mode and a sleep mode
   [PowerMgmt].









Hong & Youn             Expires January 16, 2014                [Page 3]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   Recently, the consideration of power saving is moved to network
   layer, too.  In 6lowpan, the Neighbor Discovery operations must
   consider the low-power wireless personal area networks such as IEEE
   802.15.4.  Because the usage of multicast signaling raises severe
   energy consumption, the Neighbor Discovery optimization for 6lowpan
   has limited the usage of multicast signaling [I-D.ietf-6lowpan-nd].

   In application layer, the CoAP has two functions such as proxy and
   cache.  The proxy function in the CoAP can cache and service requests
   for sleepy servers.  Thus, a client sends a CoAP request to a proxy
   on behalf of an origin server of sleep mode and then it respond
   directly to the client through the proxy.  Otherwise if the proxy has
   an invalid representation of the resource in its cache, the proxy has
   to attempt to get the valid resource from an origin server of sleep
   mode.  The attempt may or may not be successful according to the
   state of the origin server [I-D.ietf-core-coap].

4.  Use Cases of communication of a sleepy node

   To describe the problem of sleepy node in constrained node networks,
   this clause describes the use cases of communication of sleepy nodes.
   The use case of communication of sleepy nodes looks like that of
   normal Internet nodes.  The difference from the communication between
   normal Internet nodes is that there are definitely different two
   types of network nodes : sleepy node and non-sleepy nodes
   [I-D.ietf-lwig-terminology].  So, the communication of sleepy nodes
   can be classified into communication between sleepy node and non-
   sleepy node and communication between sleepy nodes.  And by the
   topology of networks, the communication can be classified into
   communication across router, communication within a router, and
   communication in ad-hoc network.

4.1.  Communication between a sleepy node and a non-sleepy node

   This use case shows the communication between one network node with
   always-on network connectivity (non-sleepy node) and one network node
   with sleepy node network capabilities.  In this use case, to provide
   the communication between a non-sleepy node and a sleepy node, it may
   require new purpose server such as a Proxy server to handle the
   request of different node with different capabilities.  In this case,
   the new purpose server will be located at the interface of network
   [I-D.jeong-eman-network-proxy-protocol].









Hong & Youn             Expires January 16, 2014                [Page 4]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


                          +--------------------+
     +---------------+    |                    |   +---------------+
     |  +---------+  |    |                    |   |  +----------+ |
     |  | Sleepy  +--+----+     Internet       +---+--+Non-Sleepy| |
     |  |  node   |  |    |                    |   |  |   node   | |
     |  +---------+  |    |                    |   |  +----------+ |
     +---------------+    |                    |   +---------------+
        Constrained       +--------------------+       General
         networks                                      networks


      Figure 1: Communication between sleepy node and non-sleepy node

4.2.  Communication between sleepy nodes

   This use case shows the communication between sleepy nodes within a
   router.  In this use case, the sleepy nodes may use same power saving
   mechanism and energy efficient technique.  And, in this use case, the
   layer 3 entities such as routers and gateways may benefits from the
   layer 2 entities such as Access Point and Base Station to keep
   synchronous sleep scheduling.


      +------------------------------+
      |                              |
      |  +--------+                  |             +---------------+
      |  | Sleepy +------+      +----+---+         |               |
      |  |  node  |      +------+        |         |               |
      |  +--------+             | Router +---------+   Internet    |
      |                  +------+        |         |               |
      |  +--------+      |      +----+---+         |               |
      |  | Sleepy +------+           |             +---------------+
      |  |  node  |                  |
      |  +--------+                  |
      |                              |
      +------------------------------+


               Figure 2: Communication between sleepy nodes

4.3.  Communication across routers

   This use case is similar to clause 3.1 and multiple hop IP
   communication is operated.  Because each network may have its own
   power saving and energy efficient mechanism, it is difficult to
   provide end-to-end level power saving and efficient mechanism.





Hong & Youn             Expires January 16, 2014                [Page 5]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


4.4.  Communication within a router

   This use is similar to clause 3.2 and 1 hop IP communication is
   mainly operated.  Because it is operated within a same router, it
   will be possible to provide efficient power saving mechanisms.

4.5.  Communication in ad-hoc network

   This use case can be happen when it is impossible to implement an
   infrastructure based wireless network and an infra-less wireless
   network is constructed.  Although there is no explicit a router, it
   may be possible to select a master and slaves and make the selected
   master do as a router to provide power saving mechanisms between
   sleepy nodes.  The efficiency of infra-less power saving may be worse
   than infrastructure-based power saving mechanism.  So, it may require
   to hybrid the infra-less power saving and infrastructure-based power
   saving.


               +--------+                        +---------+
               | Sleepy +-----------+------------+ Sleepy  |
               |  node  +           |            +  node   |
               +--------+           |            +---------+
                                    |
                               +----+----+
                               | Sleepy  |
                               |  node   |
                               +---------+


                 Figure 3: Communication in ad-hoc network

5.  Problem statement of communication of a sleepy node

5.1.  Problems of a sleepy node in Network layer

   The main problems of a sleepy node are related to neighbor discovery
   [RFC4861].  Among neighbor discovery operations, the operations
   related to multicast signaling affects severely energy efficiency.
   So, in 6lowpan-nd, the usage of multicast Neighbor Discovery messages
   has the limitation with some exception such as initial set of default
   routers.  Because of the limitation of multicast Neighbor Discovery
   messages, new address assignment with Address Registration Option
   (ARO) and different Duplicate Address Detection (DAD) mechanisms are
   used in 6lowpan-nd [I-D.ietf-6lowpan-nd].

   Another problem of a sleepy node in network layer is the choosing the
   proper a sleep time appropriate for its energy characteristics.  Even



Hong & Youn             Expires January 16, 2014                [Page 6]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   though the corresponding node is not down or the route path to the
   corresponding node is not broken, an inappropriate sleep time leads
   wrong operations.  If the modification of Neighbor Discovery such as
   6lowpan-nd is applied to network layer in all network nodes, the
   problems of a sleepy node in network layer may be decreased.  In
   realistic, this modification of Neighbor Discovery such as 6lowpan-nd
   seems that impossible because there are various wireless networks.

5.2.  Problems of a sleepy node in Transport layer

   The most constrained environments consist of interoperable IP-capable
   devices.  Thus, a constrained node needs UDP/TCP of transport layer
   for an end-to-end data transmission service.  However a constrained
   node, creating constrained node networks, is a small device such as
   sensor device with limited CPU, memory, and power resources.  In
   addition, implementing the whole functionality of the UDP/TCP in a
   small device becomes a burden.  Thus, constrained nodes must
   implement a minimal functionality for transport service demanded by
   application in constrained node.

   In [I-D.ietf-lwig-guidance], light-weight implementation of transport
   layer must be considered in a constrained node.  Also, the analysis
   of functionality of the transport protocol is needed to support an
   end-to-end communication between a non-sleepy node and a sleepy node.

   As transport protocol in constrained node with the limit memory, UDP
   has many advantages.  In particular, UDP has a very low overhead for
   both header size and protocol procedure.  This means that UDP will be
   used as the transport protocol of constrained node in constrained
   node networks because the packet transmissions and receptions consume
   less energy and the small space of memory for UDP is needed.  This
   is, the reason is that the CoAP uses UDP as transport protocol to
   transmit the message of the CoAP.  Nevertheless, UDP has drawback
   that is UDP does not provide any recovery mechanism for lost data.
   Also, UDP does not have any functionality to support a sleepy node.
   Thus, source node does not know that data may or may not be
   successful to the destination node.

   TCP has more overhead for both header size and protocol procedure
   than UDP to be implemented as transport protocol in constrained node.
   Thus, TCP implementation with the whole functionality in a small
   device occurs several compelling problems.  And it also is not aware
   to the sleep mode of destination node.  TCP protocol is a complex
   protocol that has a reliable mechanism and the mechanisms such as the
   sliding window algorithm and congestion control for high throughput.
   However, the core of TCP is quite simple because many of the complex
   mechanisms are to improve high-throughput performance.  Thus, because
   high throughput is not a requirement of any end-to-end communication



Hong & Youn             Expires January 16, 2014                [Page 7]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   in most constrained environments, several mechanisms in TCP are not
   needed TCP mechanism, such as the sliding window algorithm and
   congestion control, for high throughput.  As UDP, TCP also does not
   have any functionality to support a sleepy node.  This is, TCP
   mistakes data loss generated by sleepy node as data loss over end-to-
   end transmission.  Thus.  TCP can perform unnecessary retransmission.
   This situation can occur in most constrained environments.

5.3.  Problems of a sleepy node in Application layer

   As the CoAP, it is up to the application to support sleepy node to
   end-to-end transport service, which also increases the complexity in
   constrained node.  Also there is still no standard transport protocol
   that can support sleepy node.  Thus, to support an end-to-end
   transport service between a sleep mode node and a non-sleep mode
   node, the analysis of transport protocols is needed.

6.  Security Considerations

   TBD.

7.  IANA Considerations

   TBD

8.  References

8.1.  Normative References

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

8.2.  Informative References

   [I-D.arkko-lwig-cellular]
              Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
              Efficient CoAP Devices for Cellular Networks", ID draft-
              arkko-lwig-cellular-00, February 2013.

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabartiy, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low Power and Lossy Networks
              (6LoWPAN)", ID draft-ietf-6lowpan-nd-21, August 2012.




Hong & Youn             Expires January 16, 2014                [Page 8]


Internet-Draft      Problem statement of Sleepy nodes          July 2013


   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", ID draft-ietf-core-coap-18,
              June 2013.

   [I-D.ietf-lwig-guidance]
              Bormann, C., "Guidance for Light-Weight Implementations of
              the Internet Protocol Suite ", ID draft-ietf-lwig-
              guidance-03, February 2013.

   [I-D.ietf-lwig-terminology]
              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained Node Networks", ID draft-ietf-lwig-
              terminology-05, July 2013.

   [I-D.jeong-eman-network-proxy-protocol]
              Jeong, S., "Network Proxy Protocol", ID draft-jeong-eman-
              network-proxy-protocol-01, February 2013.

   [PowerMgmt]
              Klues, K., "Power Management in Wireless Networks",
              Report, for Advanced Topics in Networking: Wireless and
              Mobile Networking by R. Jain, Wash. Univ. in St. Louis, ,
              2006.

Authors' Addresses

   Yong-Geun Hong
   ETRI
   218 Gajeong-ro Yuseung-Gu
   Daejeon  305-700
   Korea

   Phone: +82 42 860 6557
   Email: yghong@etri.re.kr


   JooSang Youn
   DONG-EUI Univ.
   Busan
   Korea

   Phone: +82 51 890 1993
   Email: joosang.youn@gmail.com







Hong & Youn             Expires January 16, 2014                [Page 9]


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