Internet DRAFT - draft-ietf-6lowpan-routing-requirements

draft-ietf-6lowpan-routing-requirements






6LoWPAN Working Group                                             E. Kim
Internet-Draft                                                      ETRI
Intended status: Informational                                 D. Kaspar
Expires: May 23, 2012                         Simula Research Laboratory
                                                                C. Gomez
                                              Universitat Politecnica de
                                                         Catalunya/i2CAT
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                       November 20, 2011


         Problem Statement and Requirements for 6LoWPAN Routing
               draft-ietf-6lowpan-routing-requirements-10

Abstract

   6LoWPANs are formed by devices that are compatible with the IEEE
   802.15.4 standard.  However, neither the IEEE 802.15.4 standard nor
   the 6LoWPAN format specification define how mesh topologies could be
   obtained and maintained.  Thus, it should be considered how 6LoWPAN
   formation and multi-hop routing could be supported.
   This document provides the problem statement and design space for
   6LoWPAN routing.  It defines the routing requirements for 6LoWPAN
   networks, considering the low-power and other particular
   characteristics of the devices and links.  The purpose of this
   document is not to recommend specific solutions, but to provide
   general, layer-agnostic guidelines about the design of 6LoWPAN
   routing, which can lead to further analysis and protocol design.
   This document is intended as input to groups working on routing
   protocols relevant to 6LoWPAN, such as the IETF ROLL WG.

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 May 23, 2012.



Kim, et al.               Expires May 23, 2012                  [Page 1]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


Copyright Notice

   Copyright (c) 2011 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
   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.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Design Space . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Reference Network Model  . . . . . . . . . . . . . . . . .  8
   4.  Scenario Considerations and Parameters for 6LoWPAN Routing . . 10
   5.  6LoWPAN Routing Requirements . . . . . . . . . . . . . . . . . 15
     5.1.  Support of 6LoWPAN Device Properties . . . . . . . . . . . 15
     5.2.  Support of 6LoWPAN Link Properties . . . . . . . . . . . . 17
     5.3.  Support of 6LoWPAN Network Characteristics . . . . . . . . 20
     5.4.  Support of Security  . . . . . . . . . . . . . . . . . . . 24
     5.5.  Support of Mesh Under Forwarding . . . . . . . . . . . . . 27
     5.6.  Support of Management  . . . . . . . . . . . . . . . . . . 27
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35














Kim, et al.               Expires May 23, 2012                  [Page 2]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


1.  Problem Statement

   6LoWPANs are formed by devices that are compatible with the IEEE
   802.15.4 standard [IEEE802.15.4].  Most of the LoWPAN devices are
   distinguished by their low bandwidth, short range, scarce memory
   capacity, limited processing capability and other attributes of
   inexpensive hardware.  The characteristics of nodes participating in
   LoWPANs are assumed to be those described in the 6LoWPAN problem
   statement [RFC4919], and the IPv6 over IEEE 802.15.4 [RFC4944]
   document which has specified how to carry IPv6 packets over IEEE
   802.15.4 and similar networks.  Whereas IEEE 802.15.4 distinguishes
   two types of devices called full-function devices (FFD) and reduced-
   function devices (RFDs), this distinction is based on some MAC layer
   features that are not always in use.  Hence, the distinction is not
   made in this document.  Nevertheless, some 6LoWPAN nodes may limit
   themselves to the role of hosts only, whereas other 6LoWPAN nodes may
   take part in routing.  This host/router distinction can correlate
   with the processing and storage capabilities of the device and power
   available in a similar way to the idea of RFDs and FFDs.

   IEEE 802.15.4 networks support star and mesh topologies.  However,
   neither the IEEE 802.15.4 standard nor the 6LoWPAN format
   specification ([RFC4944]) define how mesh topologies could be
   obtained and maintained.  Thus, 6LoWPAN formation and multi-hop
   routing can be supported either below the IP layer (the adaptation
   layer or LLC) or the IP layer.  (Note that in the IETF, the term
   "routing" usually, but not always [RFC5556], refers exclusively to
   the formation of paths and the forwarding at the IP layer.  In this
   document we distinguish the layer at which these services are
   performed by the terms "Route Over" and "Mesh Under".  See Section 2
   and Section 3.)  A number of IP routing protocols have been developed
   in various IETF working groups.  However, these existing routing
   protocols may not satisfy the requirements of multi-hop routing in
   6LoWPANs, for the following reasons:

   o  6LoWPAN nodes have special types and roles, such as nodes drawing
      their power from primary batteries, power-affluent nodes, mains-
      powered and high-performance gateways, data aggregators, etc.
      6LoWPAN routing protocols should support multiple device types and
      roles.

   o  More stringent requirements apply to LoWPANs, as opposed to higher
      performance or non-battery-operated networks. 6LoWPAN nodes are
      characterized by small memory sizes, low processing power, and are
      running on very limited power supplied by primary non-rechargeable
      batteries (a few kBytes of RAM, a few dozens of kBytes of ROM/
      flash memory, and a few MHz of CPU is typical).  A node's lifetime
      is usually defined by the lifetime of its battery.



Kim, et al.               Expires May 23, 2012                  [Page 3]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


   o  Handling sleeping nodes is very critical in LoWPANs, more than in
      traditional ad-hoc networks.  LoWPAN nodes might stay in sleep
      mode for most of the time.  Taking advantage of appropriate times
      for transmissions is important for efficient packet forwarding.

   o  Routing in 6LoWPANs might possibly translate to a simpler problem
      than routing in higher-performance networks.  LoWPANs might be
      either transit networks or stub networks.  Under the assumption
      that LoWPANs are never transit networks (as implied by [RFC4944]),
      routing protocols may be drastically simplified.  This document
      will focus on the requirements for stub networks.  Additional
      requirements may apply to transit networks.

   o  Routing in LoWPANs might possibly translate to a harder problem
      than routing in higher-performance networks.  Routing in LoWPANs
      requires power optimization, stable operation in lossy
      environments, etc.  These requirements are not easily satisfiable
      all at once [I-D.ietf-roll-protocols-survey].

   These properties create new challenges on design of routing within
   LoWPANs.

   The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals"
   [RFC4919]) briefly mentions four requirements on routing protocols:

      (a) low overhead on data packets

      (b) low routing overhead

      (c) minimal memory and computation requirements

      (d) support for sleeping nodes considering battery saving

   These four high-level requirements describe the basic requirements
   for 6LoWPAN routing.  Based on the fundamental features of 6LoWPAN,
   more detailed routing requirements are presented in this document,
   which can lead to further analysis and protocol design.

   Considering the problems above, detailed 6LoWPAN routing requirements
   must be defined.  Application-specific features affect the design of
   6LoWPAN routing requirements and the corresponding solutions.
   However, various applications can be profiled by similar technical
   characteristics, although the related detailed requirements might
   differ (e.g., a few dozens of nodes in a home lighting system need
   appropriate scalability for its applications, while millions of nodes
   for a highway infrastructure system also need appropriate
   scalability).




Kim, et al.               Expires May 23, 2012                  [Page 4]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


   This routing requirements document states the routing requirements of
   6LoWPAN applications in general, providing examples for different
   cases of routing.  It does not imply a single routing solution to be
   favorable for all 6LoWPAN applications and there is no requirement of
   different routing protocols to run simultaneously.














































Kim, et al.               Expires May 23, 2012                  [Page 5]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


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

   Readers are expected to be familiar with all the terms and concepts
   that are discussed in "IPv6 over Low-Power Wireless Personal Area
   Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
   Goals" [RFC4919], and "Transmission of IPv6 Packets over IEEE
   802.15.4 Networks" [RFC4944].

   This specification makes use of the terminology defined in the
   "Neighbor Discovery for 6LoWPAN" [I-D.ietf-6lowpan-nd].





































Kim, et al.               Expires May 23, 2012                  [Page 6]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


3.  Design Space

   Apart from a wide variety of conceivable routing algorithms for
   6LoWPAN, it is possible to perform routing in the IP layer, using a
   Route Over approach or below IP, as defined by the 6LoWPAN format
   document [RFC4944], using the Mesh Under approach (see Figure 1).

   The Route Over approach relies on IP routing and therefore supports
   routing over possibly various types of interconnected links.
   Note: The ROLL WG is now working on Route Over approaches for Low
   power and Lossy Networks (LLNs), not specifically for 6LoWPAN.  This
   document focuses on 6LoWPAN-specific requirements; it may be used in
   conjunction with the more application-oriented requirements defined
   by the ROLL WG.

   The Mesh Under approach performs the multi-hop communication below
   the IP link.  The most significant consequence of Mesh Under
   mechanism is that the characteristics of IEEE 802.15.4 directly
   affect the 6LoWPAN routing mechanisms, including the use of 64-bit
   (or 16-bit short) link layer addresses instead of IP addresses.  A
   6LoWPAN would therefore be seen as a single IP link.

   Most statements in this document consider both the Route Over and
   Mesh Under cases.



























Kim, et al.               Expires May 23, 2012                  [Page 7]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


   Figure 1 shows the place of 6LoWPAN routing in the entire network
   stack.

    +---------------------------+  +-----------------------------+
    |      Application Layer    |  |      Application Layer      |
    +---------------------------+  +-----------------------------+
    | Transport Layer (TCP/UDP) |  |  Transport Layer (TCP/UDP)  |
    +---------------------------+  +-----------------------------+
    |     Network Layer (IPv6)  |  |  Network       +---------+  |
    +---------------------------+  |  Layer         | Routing |  |
    |  6LoWPAN                  |  |  (IPv6)        +---------+  |
    |  Adaptation               |  +-----------------------------+
    |  Layer       +----------+ |  |  6LoWPAN Adaptation Layer   |
    +--------------| Routing* |-+  +-----------------------------+
    | 802.15.4 MAC +----------+ |  |        802.15.4 MAC         |
    +---------------------------+  +-----------------------------+
    |         802.15.4 PHY      |  |        802.15.4 PHY         |
    +---------------------------+  +-----------------------------+
     * Here, 'Routing' is not equivalent to IP routing,
       but includes the functionalities of path computation and
       forwarding under the IP layer.
       The term 'Routing' is used in the figure in order to
       illustrate which layer handles path computation and
       packet forwarding in Mesh Under compared to Route Over.

        Figure 1: Mesh Under (left) and Route Over routing (right)

   In order to avoid packet fragmentation and the overhead for
   reassembly, routing packets should fit into a single IEEE 802.15.4
   physical frame and application data should not be expanded to an
   extent that they no longer fit.

3.1.  Reference Network Model

   For multi-hop communication in 6LoWPAN, when a Route Over mechanism
   is in use, all routers (i.e. 6LoWPAN Border Routers (6LBRs) and
   6LoWPAN Routers (6LRs)) perform IP routing within the stub network
   (see Figure 2).  In this case, the link-local scope covers the set of
   nodes within symmetric radio range of a node.

   When a LoWPAN follows the Mesh Under configuration, the 6LBR is the
   only IPv6 router in the LoWPAN (see Figure 3).  This means that the
   IPv6 link-local scope includes all nodes in the LoWPAN.  For this, a
   Mesh Under mechanism MUST be provided to support multi-hop
   transmission.






Kim, et al.               Expires May 23, 2012                  [Page 8]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


        h   h
       /    |                     6LBR: 6LoWPAN Border Router
   6LBR -- 6LR --- 6LR --- h       6LR: 6LoWPAN Router
           / \                       h: Host
          h  6LR --- h
              |
             / \
          6LR - 6LR -- h

                Figure 2: An example of a Route Over LoWPAN


        h   h
       /    |                    6LBR: 6LoWPAN Border Router
   6LBR --- m --- m --- h           m: mesh under forwarder
           / \                      h: Host
          h   m --- h
              |
             / \
            m - m -- h

                Figure 3: An example of a Mesh Under LoWPAN

   Note than in both Mesh Under and Route Over networks, there is no
   expectation of topologically based address assignment in the 6LoWPAN.
   Instead, addresses are typically assigned based on the EUI-64
   addresses assigned at manufacturing time to nodes, or based on a
   (from a topological point of view) more or less random process
   assigning 16-bit MAC addresses to individual nodes.  Within a
   6LoWPAN, there is therefore no opportunity for aggregation or
   summarization of IPv6 addresses beyond the sharing of (one or more)
   common prefixes.

   Not all devices that are in radio range of each other need to be part
   of the same LoWPAN.  When multiple LoWPANs are formed with globally
   unique IPv6 addresses in the 6LoWPANs, and device (a) of LoWPAN [A]
   wants to communicate with device (b) of LoWPAN [B], the normal IPv6
   mechanisms will be employed.  For Route Over, the IPv6 address of (b)
   is set as the destination of the packets, and the devices perform IP
   routing to the 6LBR for these outgoing packets.  For Mesh Under,
   there is one IP hop from a device (a) to the 6LBR of [A], no matter
   how many radio hops they are apart from each other.  This, of course,
   assumes the existence of a Mesh Under routing protocol in order to
   reach the 6LBR.  Note that a default route to the 6LBR could be
   inserted into the 6LoWPAN routing system for both Route Over and Mesh
   Under.





Kim, et al.               Expires May 23, 2012                  [Page 9]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


4.  Scenario Considerations and Parameters for 6LoWPAN Routing

   IP-based LoWPAN technology is still in its early stage of
   development, but the range of conceivable usage scenarios is
   tremendous.  The numerous possible applications of sensor networks
   make it obvious that mesh topologies will be prevalent in LoWPAN
   environments and robust routing will be a necessity for expedient
   communication.  Research efforts in the area of sensor networking
   have put forth a large variety of multi-hop routing algorithms
   [refs.bulusu].  Most related work focuses on optimizing routing for
   specific application scenarios, which can be realized using several
   models of communication, including the following ones [refs.cctc]:

   o  Flooding (in very small networks)

   o  Hierarchical routing

   o  Geographic routing

   o  Self-organizing coordinate routing

   Depending on the topology of a LoWPAN and the application(s) running
   over it, different types of routing may be used.  However, this
   document abstracts from application-specific communication and
   describes general routing requirements valid for overall routing in
   LoWPANs.

   The following parameters can be used to describe specific scenarios
   in which the candidate routing protocols could be evaluated.

   a.  Network Properties:

       *  Number of Devices, Density and Network Diameter:
          These parameters usually affect the routing state directly
          (e.g. the number of entries in a routing table or neighbor
          list).  Especially in large and dense networks, policies must
          be applied for discarding "low-quality" and stale routing
          entries in order to prevent memory overflow.

       *  Connectivity:
          Due to external factors or programmed disconnections, a LoWPAN
          can be in several states of connectivity; anything in the
          range from "always connected" to "rarely connected".  This
          poses great challenges to the dynamic discovery of routes
          across a LoWPAN.

       *  Dynamicity (including mobility):
          Location changes can be induced by unpredictable external



Kim, et al.               Expires May 23, 2012                 [Page 10]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


          factors or by controlled motion, which may in turn cause route
          changes.  Also, nodes may dynamically be introduced into a
          LoWPAN and removed from it later.  The routing state and the
          volume of control messages may heavily depend on the number of
          moving nodes in a LoWPAN and their speed, as well as how
          quickly and frequently environmental characteristics
          influencing radio propagation change.

       *  Deployment:
          In a LoWPAN, it is possible for nodes to be scattered randomly
          or to be deployed in an organized manner.  The deployment can
          occur at once, or as an iterative process, which may also
          affect the routing state.

       *  Spatial Distribution of Nodes and Gateways:
          Network connectivity depends on the spatial distribution of
          the nodes and on other factors, such as device number, density
          and transmission range.  For instance, nodes can be placed on
          a grid, or randomly located in an area (as can be modeled by a
          bidimensional Poisson distribution), etc.  Assuming a random
          spatial distribution, an average of 7 neighbors per node are
          required for approximately 95% network connectivity (10
          neighbors per node are needed for 99%
          connectivity)[refs.Kuhn].  In addition, if the LoWPAN is
          connected to other networks through infrastructure nodes
          called gateways, the number and spatial distribution of
          gateways affects network congestion and available data rate,
          among others.

       *  Traffic Patterns, Topology and Applications:
          The design of a LoWPAN and the requirements on its application
          have a big impact on the network topology and the most
          efficient routing type to be used.  For different traffic
          patterns (point-to-point, multipoint-to-point, point-to-
          multipoint) and network architectures, various routing
          mechanisms have been developed, such as data-centric, event-
          driven, address-centric, and geographic routing.

       *  Classes of Service:
          For mixing applications of different criticality on one
          LoWPAN, support of multiple classes of service may be required
          in resource-constrained LoWPANs and may require a new routing
          protocol functionality.

       *  Security:
          LoWPANs may carry sensitive information and require a high
          level of security support where the availability, integrity,
          and confidentiality of data are of prime relevance.  Secured



Kim, et al.               Expires May 23, 2012                 [Page 11]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


          messages cause overhead and affect the power consumption of
          LoWPAN routing protocols.

   b.  Node Parameters:

       *  Processing Speed and Memory Size:
          These basic parameters define the maximum size of the routing
          state and the maximum complexity of its processing.  LoWPAN
          nodes may have different performance characteristics, queuing
          strategies and queue buffer sizes.

       *  Power Consumption and Power Source:
          The number of battery- and mains-powered nodes and their
          positions in the topology created by them in a LoWPAN affect
          routing protocols in their selection of paths that optimize
          network lifetime.

       *  Transmission Range:
          This parameter affects routing.  For example, a high
          transmission range may cause a dense network, which in turn
          results in more direct neighbors of a node, higher
          connectivity and a larger routing state.

       *  Traffic Pattern:
          This parameter affects routing since highly loaded nodes
          (either because they are the source of packets to be
          transmitted or due to forwarding) may contribute to higher
          delivery delays and may consume more energy than lightly
          loaded nodes.  This applies to both data packets and routing
          control messages.

   c.  Link Parameters:
       This section discusses link parameters that apply to IEEE
       802.15.4 legacy mode (i.e. not making use of improved modulation
       schemes).

       *  Throughput:
          The maximum user data throughput of a bulk data transmission
          between a single sender and a single receiver through an
          unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is
          as follows [refs.Latre]:

          +  16-bit MAC addresses, unreliable mode: 151.6 kbit/s

          +  16-bit MAC addresses, reliable mode: 139.0 kbit/s

          +  64-bit MAC addresses, unreliable mode: 135.6 kbit/s




Kim, et al.               Expires May 23, 2012                 [Page 12]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


          +  64-bit MAC addresses, reliable mode: 124.4 kbit/s

          In the case of 915 MHz band:

          +  16-bit MAC addresses, unreliable mode: 31.1 kbit/s

          +  16-bit MAC addresses, reliable mode: 28.6 kbit/s

          +  64-bit MAC addresses, unreliable mode: 27.8 kbit/s

          +  64-bit MAC addresses, reliable mode: 25.6 kbit/s

          In the case of 868 MHz band:

          +  16-bit MAC addresses, unreliable mode: 15.5 kbit/s

          +  16-bit MAC addresses, reliable mode: 14.3 kbit/s

          +  64-bit MAC addresses, unreliable mode: 13.9 kbit/s

          +  64-bit MAC addresses, reliable mode: 12.8 kbit/s

       *  Latency:
          The range of latencies, depending on payload size, of a frame
          transmission between a single sender and a single receiver
          through an unslotted IEEE 802.15.4 2.4 GHz channel in ideal
          conditions are as shown next [refs.Latre].  For unreliable
          mode, the actual latency is provided.  For reliable mode, the
          round-trip-time including transmission of a layer two
          acknowledgment is provided:

          +  16-bit MAC addresses, unreliable mode: [1.92 ms, 6.02 ms]

          +  16-bit MAC addresses, reliable mode: [2.46 ms, 6.56 ms]

          +  64-bit MAC addresses, unreliable mode: [2.75 ms, 6.02 ms]

          +  64-bit MAC addresses, reliable mode: [3.30 ms, 6.56 ms]

          For the 915 MHz band:

          +  16-bit MAC addresses, unreliable mode: [5.85 ms, 29.35 ms]

          +  16-bit MAC addresses, reliable mode: [8.35 ms, 31.85 ms]

          +  64-bit MAC addresses, unreliable mode: [8.95 ms, 29.35 ms]





Kim, et al.               Expires May 23, 2012                 [Page 13]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


          +  64-bit MAC addresses, reliable mode: [11.45 ms, 31.85 ms]

          For the 868 MHz band:

          +  16-bit MAC addresses, unreliable mode: [11.7 ms, 58.7 ms]

          +  16-bit MAC addresses, reliable mode: [16.7 ms, 63.7 ms]

          +  64-bit MAC addresses, unreliable mode: [17.9 ms, 58.7 ms]

          +  64-bit MAC addresses, reliable mode: [22.9 ms, 63.7 ms]

   Note that some of the parameters presented in this section may be
   used as link or node evaluation metrics.  However, multi-criteria
   routing may be too expensive for 6LoWPAN nodes.  Rather, various
   single-criteria metrics are available and can be selected to suit the
   environment or application.


































Kim, et al.               Expires May 23, 2012                 [Page 14]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


5.  6LoWPAN Routing Requirements

   This section defines a list of requirements for 6LoWPAN routing.  An
   important design property specific to low-power networks is that
   LoWPANs have to support multiple device types and roles, such as:

   o  host nodes drawing their power from primary batteries or using
      energy harvesting (both called "power-constrained nodes" in the
      following)

   o  mains-powered host nodes (an example for what we call "power-
      affluent nodes")

   o  power-affluent (but not necessarily mains-powered) high-
      performance gateway(s)

   o  nodes with various functionality (data aggregators, relays, local
      manager/coordinators, etc.)

   Due to these different device types and roles LoWPANs need to
   consider the following two primary attributes:

   o  Power conservation: some devices are mains-powered, but many are
      battery-operated and need to last several months to a few years
      with a single AA battery.  Many devices are mains-powered most of
      the time, but still need to function for possibly extended periods
      from batteries (e.g. on a construction site before building power
      is switched on for the first time).

   o  Low performance: tiny devices, small memory sizes, low-performance
      processors, low bandwidth, high loss rates, etc.

   These fundamental attributes of LoWPANs affect the design of routing
   solutions.  Whether existing routing specifications are simplified
   and modified, or new solutions are introduced in order to fit the
   low-power requirements of LoWPANs, they need to meet the requirements
   described in the following.

5.1.  Support of 6LoWPAN Device Properties

   The general objectives listed in this section should be met by
   6LoWPAN routing protocols.  The importance of each requirement is
   dependent on what node type the protocol is running on and what the
   role of the node is.  The following requirements consider the
   presence of battery-powered nodes in LoWPANs.

   [R01] 6LoWPAN routing protocols SHOULD allow implementation with
   small code size and require low routing state to fit the typical



Kim, et al.               Expires May 23, 2012                 [Page 15]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


   6LoWPAN node capacity.  Generally speaking, the code size is bounded
   by available flash memory size, and the routing table is bounded by
   RAM size, possibly limiting it to less than 32 entries.

      The RAM size of LoWPAN nodes often ranges between 4 kB (2 kB
      minimum) and 10 kB, and program flash memory normally consists of
      48 kB to 128 kB. (e.g., in the current market, MICAz has 128 kB
      program flash, 4 kB EEPROM, 512 kB external flash ROM; TIP700CM
      has 48 kB program flash, 10 kB RAM, 1 MB external flash ROM).

      Due to these hardware restrictions, code SHOULD fit within a small
      memory size; no more than 48 kB to 128 kB of flash memory
      including at least a few tens of KB of application code size.  (As
      a general observation, a routing protocol of low complexity may
      help achieving the goal of reducing power consumption, improves
      robustness, requires lower routing state, is easier to analyze,
      and may be less prone to security attacks.)

      In addition, operation with limited amounts of routing state (such
      as routing tables and neighbor lists) SHOULD be maintained since
      some typical memory sizes preclude storing state of a large number
      of nodes.  For instance, industrial monitoring applications may
      need to support at maximum 20 hops [RFC5673].  Small networks can
      be designed to support a smaller number of hops.  While the need
      for this is highly dependent on the network architecture, there
      should be at least one mode of operation that can function with 32
      forwarding entries or less.

   [R02] 6LoWPAN routing protocols SHOULD cause minimal power
   consumption by the efficient use of control packets (e.g., minimize
   expensive IP multicast which causes link broadcast to the entire
   LoWPAN) and by the efficient routing of data packets.

      One way of battery lifetime optimization is by achieving a minimal
      control message overhead.  Compared to functions such as
      computational operations or taking sensor samples, radio
      communications is by far the dominant factor of power consumption
      [refs.SmartDust].  Power consumption of transmission and/or
      reception depends linearly on the length of data units and on the
      frequency of transmission and reception of the data units
      [refs.Shih].

      The energy consumption of two example RF controllers for low-power
      nodes is shown in [refs.Hill].  The TR1000 radio consumes 21 mW
      when transmitting at 0.75 mW, and 15 mW on reception (with a
      receiver sensitivity of -85 dBm).  The CC1000 consumes 31.6 mW
      when transmitting 0.75 mW, and 20 mW for receiving (with a
      receiver sensitivity of -105 dBm).  The power endurance under the



Kim, et al.               Expires May 23, 2012                 [Page 16]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      concept of an idealized power source is explained in [refs.Hill].
      Based on the energy of an idealized AA battery, the CC1000 can
      transmit for approximately 4 days straight or receive for 9
      consecutive days.  Note that availability for reception consumes
      power as well.

      As multicast may cause flooding in the LoWPAN, a 6LoWPAN routing
      protocol SHOULD minimize the control cost by multicasting routing
      packets.

      Control cost of routing protocols in low power and lossy networks
      is discussed in more detail in [I-D.ietf-roll-protocols-survey].

5.2.  Support of 6LoWPAN Link Properties

   6LoWPAN links have the characteristics of low data rate and possibly
   high loss rates.  The routing requirements described in this section
   are derived from the link properties.

   [R03] 6LoWPAN routing protocol control messages SHOULD NOT exceed a
   single IEEE 802.15.4 frame size in order to avoid packet
   fragmentation and the overhead for reassembly.

      In order to save energy, routing overhead should be minimized to
      prevent fragmentation of frames.  Therefore, 6LoWPAN routing
      should not cause packets to exceed the IEEE 802.15.4 frame size.
      This reduces the energy required for transmission, avoids
      unnecessary waste of bandwidth, and prevents the need for packet
      reassembly.  As calculated in RFC4944 [RFC4944], the maximum size
      of a 6LoWPAN frame, in order not to cause fragmentation, is 81
      octets.  This may imply the use of semantic fragmentation and/or
      algorithms that can work on small increments of routing
      information.

   [R04] The design of routing protocols for LoWPANs must consider the
   fact that packets are to be delivered with sufficient probability
   according to application requirements.

      Requirements on successful end-to-end packet delivery ratio (where
      delivery may be bounded within certain latency) vary depending on
      applications.  In industrial applications, some non-critical
      monitoring applications may tolerate successful delivery ratio of
      less than 90% with hours of latency; in some other cases, a
      delivery ratio of 99.9% is required [RFC5673].  In building
      automation applications, application layer errors must be below
      0.01% [RFC5867].





Kim, et al.               Expires May 23, 2012                 [Page 17]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      Successful end-to-end delivery of packets in an IEEE 802.15.4 mesh
      depends on the quality of the path selected by the routing
      protocol and on the ability of the routing protocol to cope with
      short-term and long-term quality variation.  The metric of the
      routing protocol strongly influences performance of the routing
      protocol in terms of delivery ratio.

      The quality of a given path depends on the individual qualities of
      the links (including the devices) that compose that path.  IEEE
      802.15.4 settings affect the quality perceived at upper layers.
      In particular, in IEEE 802.15.4 reliable mode, if an
      acknowledgment frame is not received after a given period, the
      originator retries frame transmission up to a maximum number of
      times.  If an acknowledgment frame is still not received by the
      sender after performing the maximum number of transmission
      attempts, the MAC layer assumes the transmission has failed and
      notifies the next higher layer of the failure.  Note that
      excessive retransmission may be detrimental, see RFC 3819
      [RFC3819].

   [R05] The design of routing protocols for LoWPANs must consider the
   latency requirements of applications and IEEE 802.15.4 link latency
   characteristics.

      Latency requirements may differ from a few hundreds milliseconds
      to minutes, depending on the type of application.  Real-time
      building automation applications usually need response times below
      500 ms between egress and ingress, while forced entry security
      alerts must be routed to one or more fixed or mobile user devices
      within 5 s [RFC5867].  Non-critical closed loop applications for
      industrial automation have latency requirements that can be as low
      as 100 ms but many control loops are tolerant of latencies above
      1 s [RFC5673].  In contrast to this, urban monitoring applications
      allow latencies smaller than the typical intervals used for
      reporting sensed information; for instance, in the order of
      seconds to minutes [RFC5548].

      The range of latencies of a frame transmission between a single
      sender and a single receiver through an ideal unslotted IEEE
      802.15.4 2.4 GHz channel is between 2.46 ms and 6.02 ms in 64 bit
      MAC address unreliable mode and 2.20 ms to 6.56 ms in 64 bit
      address reliable mode.  The range of latencies of 868 MHz band is
      from 11.7 ms to 63.7 ms, depending on the address type and
      reliable/unreliable mode used.  Note that the latencies may be
      larger than that depending on channel load, MAC layer settings
      procedure, and reliable/unreliable mode choice.  Note that other
      MAC approaches than the legacy 802.15.4 may be used (e.g.  TDMA).
      Duty cycling may further affect latency (see [R08]).  Depending on



Kim, et al.               Expires May 23, 2012                 [Page 18]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      the routing path chosen and the network diameter, multiple of
      these hops may contribute to the end-to-end latency that
      application experience.

      Note that a tradeoff exists between [R05] and [R04].

   [R06] 6LoWPAN routing protocols SHOULD be robust to dynamic loss
   caused by link failure or device unavailability either in the short
   term (ca. 30 ms), due to RSSI variation, interference variation,
   noise and asynchrony, or in the long term, due to a depleted power
   source, hardware breakdown, operating system misbehavior, etc.

      An important trait of 6LoWPAN devices is their unreliability due
      to limited system capabilities, and also because they might be
      closely coupled to the physical world with all its unpredictable
      variation.  In harsh environments, LoWPANs easily suffer from link
      failure.  Collision or link failure easily increases send and
      receive queues and can lead to queue overflow and packet losses.

      For home applications, where users expect feedback after carrying
      out actions (such as handling a remote control while moving
      around), routing protocols must converge within 2 seconds if the
      destination node of the packet has moved and must converge within
      0.5 seconds if only the sender has moved [RFC5826].  The tolerance
      of the recovery time can vary depending on the application,
      however, the routing protocol must provide the detection of short-
      term unavailability and long-term disappearance.  The routing
      protocol has to exploit network resources (e.g. path redundancy)
      to offer good network behavior despite of node failure.

      Different routing protocols may exhibit different scaling
      characteristics with respect to the recovery/convergence time and
      the computational resources to achieve recovery after a
      convergence, hence see also R01/R10.

   [R07] 6LoWPAN routing protocols SHOULD be designed to correctly
   operate in the presence of link asymmetry.

      Link asymmetry occurs when the probability of successful
      transmission between two nodes is significantly higher in one
      direction than in the other one.  This phenomenon has been
      reported in a large number of experimental studies and it is
      expected that 6LoWPANs will exhibit link asymmetry.








Kim, et al.               Expires May 23, 2012                 [Page 19]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


5.3.  Support of 6LoWPAN Network Characteristics

   6LoWPANs can be deployed in different sizes and topologies, adhere to
   various models of mobility, be exposed to various levels of
   interference, etc.  In any case, LoWPANs must maintain low energy
   consumption.  The requirements described in the following subsection
   are derived from the network attributes of 6LoWPANs.

   [R08] The design of 6LoWPAN routing protocols SHOULD take into
   account that some nodes may be unresponsive during certain time
   intervals due to periodic hibernation.

      Many nodes in LoWPAN environments might periodically hibernate
      (i.e. disable their transceiver activity) in order to save energy.
      Therefore, routing protocols must ensure robust packet delivery
      despite nodes frequently shutting off their radio transmission
      interface.  Feedback from the lower IEEE 802.15.4 layer may be
      considered to enhance the power-awareness of 6LoWPAN routing
      protocols.

      CC1000-based nodes must operate at a duty cycle of approximately
      2% to survive for one year from idealized AA battery power source
      [refs.Hill].  For home automation purposes, it is suggested that
      the devices have to maximize the sleep phase with a duty cycle
      lower than 1% [RFC5826], while in building automation
      applications, batteries must be operational for at least 5 years
      when the sensing devices are transmitting data (e.g. 64 bytes)
      once per minute [RFC5867].

      Dependent on the application in use, packet rates may range from
      one per second to one per day or beyond.  Routing protocols may
      take advantage of knowledge about the packet transmission rate and
      utilize this information in calculating routing paths.  In many
      IEEE 802.15.4 deployments, and in other wireless low-power
      technologies, forwarders are mains-powered devices (and hence do
      not need to sleep).  However, it cannot be assumed that all
      forwarders are mains-powered.  A routing protocol that addresses
      this case SHOULD provide a mode in which power consumption is a
      metric.  In addition, using nodes in power-saving modes for
      forwarding may increase delay and reduce packet delivery
      probability, which in this case also should be available as an
      input into the path computation.

   [R09] The metric used by 6LoWPAN routing protocols SHOULD provide
   some flexibility with respect to the inputs provided by the lower
   layers and other measures to optimize path selection considering
   energy balance and link qualities.




Kim, et al.               Expires May 23, 2012                 [Page 20]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      In homes, buildings, or infrastructure, some nodes will be
      installed with mains power.  Such power-installed nodes MUST be
      considered as relay points for a prominent role in packet
      delivery. 6LoWPAN routing protocols MUST know the power
      constraints of the nodes.

      Simple hop-count-only mechanisms may be inefficient in 6LoWPANs.
      There is a Link Quality Indication (LQI), or/and RSSI from IEEE
      802.15.4 that may be taken into account for better metrics.  The
      metric to be used (and its goal) may depend on applications and
      requirements.

      The numbers in Figure 4 represent the Link Delivery Ratio (LDR) of
      each pair of nodes.  There are studies that show a piecewise
      linear dependence between LQI and LDR [refs.Chen].




                                     0.6
                                  A-------C
                                   \     /
                                0.9 \   / 0.9
                                     \ /
                                      B

                         Figure 4: An example network

      In this simple example, there are two options in routing from node
      A to node C, with the following features:

      A.  Path AC:

          +  (1/0.6) = 1.67 avg. transmissions needed for each packet
             (confirmed link layer delivery with retransmissions and
             negligible ACK loss have been assumed)

          +  one-hop path

          +  good in energy consumption and end-to-end latency of data
             packets, bad in delivery ratio (0.6)

          +  bad in probability of route reconfigurations

      B.  Path ABC:

          +  (1/0.9)+(1/0.9) = 2.22 avg. transmissions needed for each
             packet (under the same assumptions as above)



Kim, et al.               Expires May 23, 2012                 [Page 21]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


          +  two-hop path

          +  bad in energy consumption and end-to-end latency of data
             packets, good in delivery ratio (0.81)

      If energy consumption of the network must be minimized, path AC is
      the best (this path would be chosen based on a hop count metric).
      However, if the delivery ratio in that case is not sufficient, the
      best path is ABC (it would be chosen by an LQI based metric).
      Combinations of both metrics can be used.

      The metric also affects the probability of route reconfiguration.
      Route reconfiguration, which may be triggered by packet losses,
      may require transmission of routing protocol messages.  It is
      possible to use a metric aimed at selecting the path with low
      route reconfiguration rate by using LQI as an input to the metric.
      Such a path has good properties, including stability and low
      control message overhead.

   Note that a tradeoff exists between [R09] and [R01].

   [R10] 6LoWPAN routing protocols SHOULD be designed to achieve both
   scalability from a few nodes to maybe millions of nodes and
   minimality in terms of used system resources.

      A LoWPAN may consist of just a couple of nodes (for instance in a
      body-area network), but may also contain much higher numbers of
      devices (e.g. monitoring of a city infrastructure or a highway).
      For home automation applications it is envisioned that the routing
      protocol must support 250 devices in the network [RFC5826], while
      routing protocols for metropolitan-scale sensor networks must be
      capable of clustering a large number of sensing nodes into regions
      containing on the order of 10^2 to 10^4 sensing nodes each
      [RFC5548].  It is therefore necessary that routing mechanisms are
      designed to be scalable for operation in various network sizes.
      However, due to a lack of memory size and computational power,
      6LoWPAN routing might limit forwarding entries to a small number,
      such as at maximum 32 routing table entries.  Specially in large
      networks, the routing mechanism MUST be designed in such a way
      that the number of routers be smaller than the number of hosts.

   [R11] The procedure of route repair and related control messages
   SHOULD NOT harm overall energy consumption from the routing
   protocols.

      Local repair improves throughput and end-to-end latency,
      especially in large networks.  Since routes are repaired quickly,
      fewer data packets are dropped, and a smaller number of routing



Kim, et al.               Expires May 23, 2012                 [Page 22]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      protocol packet transmissions are needed since routes can be
      repaired without source initiated Route Discovery [refs.Lee].  One
      important consideration here may be to avoid premature energy
      depletion, even in case that impairs other requirements.

   [R12] 6LoWPAN routing protocols SHOULD allow for dynamically adaptive
   topologies and mobile nodes.  When supporting dynamic topologies and
   mobile nodes, route maintenance should keep in mind the goal of a
   minimal routing state and routing protocol message overhead.

      Topological node mobility may be the result of physical movement
      and/or of a changing radio environment; making it very likely that
      mobility needs to be handled even in a network with physically
      static nodes. 6LoWPAN does not make use of a separate protocol to
      maintain connectivity to moving nodes but expects the routing
      protocol to handle it.

      In addition, some nodes may move from one 6LoWPAN to another and
      are expected to become functional members of the latter 6LoWPAN in
      a limited amount of time.

      Building monitoring applications, for instance, have a number of
      requirements with respect to recovery and settling time for
      mobility that range between 5 and 20 seconds (section 5.3.1 of
      [RFC5867]).  For more interactive applications such as used in
      home automation systems, where users are giving input and expect
      instant feedback, mobility requirements are also stricter and, for
      moves within a network, a convergence time below 0.5 seconds is
      commonly required (section 3.2 of [RFC5826]).  In industrial
      environments, where mobile equipment such as cranes move around,
      the support of vehicular speeds of up to 35 km/h are required to
      be supported by the routing protocol [RFC5673].  Currently,
      6LoWPANs are not normally being used for such a fast mobility, but
      dynamic association and disassociation MUST be supported in
      6LoWPAN.

      There are several challenges that should be addressed by a 6LoWPAN
      routing protocol in order to create robust routing in dynamic
      environments:

      *  Mobile nodes changing their location inside a LoWPAN:
         If the nodes' movement pattern is unknown, mobility cannot
         easily be detected or distinguished by the routing protocols.
         Mobile nodes can be treated as nodes that disappear and re-
         appear in another place.  Movement pattern tracking increases
         complexity and can be avoided by handling moving nodes using
         reactive route updates.




Kim, et al.               Expires May 23, 2012                 [Page 23]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      *  Movement of a LoWPAN with respect to other (inter)connected
         LoWPANs:
         Within each stub network, (one or more) relatively powerful
         gateway nodes (6LBRs) need to be configured to handle moving
         LoWPANs.

      *  Nodes permanently joining or leaving the LoWPAN:
         In order to ease routing table updates, reduce their size, and
         minimize error control messages, nodes leaving the network may
         announce their disassociation to the closest edge router or, if
         any, to a specific node that takes charge of local association
         and disassociation.

   [R13] A 6LoWPAN routing protocol SHOULD support various traffic
   patterns: point-to-point, point-to-multipoint, and multipoint-to-
   point, while avoiding excessive multicast traffic in a LoWPAN.

      6LoWPANs often have point-to-multipoint or multipoint-to-point
      traffic patterns.  Many emerging applications include point-to-
      point communication as well. 6LoWPAN routing protocols should be
      designed with the consideration of forwarding packets from/to
      multiple sources/destinations.  Current documents of the ROLL
      working group explain that the workload or traffic pattern of use
      cases for LoWPANs tends to be highly structured, unlike the any-
      to-any data transfers that dominate typical client and server
      workloads.  In many cases, exploiting such structure may simplify
      difficult problems arising from resource constraints or variation
      in connectivity.

5.4.  Support of Security

   The routing requirement described in this subsection allows secure
   transmission of routing messages.  As in traditional networks,
   routing mechanisms in 6lowpan present another window from which, an
   attacker might disrupt and significantly degrade the 6lowpan overall
   performance.  Attacks against unsecure routing aim mainly to
   contaminate WPAN networks with false routing information resulting in
   routing inconsistencies.  A malicious node can also snoop packets and
   then launch replay attacks on the 6lowpan nodes.  These attacks can
   cause harm especially when the attacker is a high-power device, such
   as laptop.  It can also easily drain 6lowpan devices batteries by
   sending broadcast messages, redirecting routes etc.

   [R14] 6LoWPAN routing protocols MUST support confidentiality,
   authentication and integrity services as required for secure delivery
   of control messages.





Kim, et al.               Expires May 23, 2012                 [Page 24]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      A general set of requirements that may apply to these services can
      be found in [I-D.ietf-karp-threats-reqs].

      Security is very important for designing robust routing protocols,
      but it should not cause significant transmission overhead.  The
      security aspect, however, seems a bit tradeoff in the 6lowpan
      since security is always a costly function. 6lowpan poses unique
      challenges to which, traditional security techniques cannot be
      applied directly.  For example, public key cryptography primitives
      are typically avoided (as being too expensive) as are relatively
      heavyweight conventional encryption methods.

      Consequently, it becomes questionable whether the 6lowpan devices
      can support IPsec as it is.  While IPsec is mandatory with IPv6,
      considering the power constraints and limited processing
      capabilities of IEEE 802.15.4 capable devices, IPsec is
      computationally expensive; Internet key exchange (IKEv2) messaging
      described in RFC5996 [RFC5996] will not work well in 6lowpans as
      we want to minimize the amount of signaling in these networks.
      IPsec supports AH for authenticating the IP header and ESP for
      authenticating and encrypting the payload.  The main issues of
      using IPsec are two-fold: (1) processing power and (2) key
      management.  Since these tiny 6lowpan devices do not process huge
      number of data or communicate with many different nodes, it is not
      well understood if complete implementation of SADB, policy-
      database and dynamic key-management protocol are appropriate for
      these small battery powered devices.

      Bandwidth is a very scarce resource in 6lowpan environments.  The
      fact that IPsec additionally requires another header (AH or ESP)
      in every packet makes its use problematic in 6lowpan environments.
      IPsec requires two communicating peers to share a secret key that
      is typically established dynamically with the Internet Key
      Exchange (IKEv2) protocol.  Thus, it has an additional packet
      overhead incurred by IKEv2 packets exchange.

      Given existing constraints in 6lowpan environments, IPsec may not
      be suitable to use in such environments, especially that 6lowpan
      node may not be able to operate all IPsec algorithms on its own
      capability.  Thus, 6lowpan may need to define its own keying
      management method(s) that requires minimum overhead in packet-size
      and in number of signaling messages exchange.  IPsec will provide
      authentication and confidentiality between end-nodes and across
      multiple lowpan- links, and may be useful only when two nodes want
      to apply security to all exchanged messages.  However, in most
      cases, the security may be requested at the application layer as
      needed, while other messages can flow in the network without
      security overhead.



Kim, et al.               Expires May 23, 2012                 [Page 25]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      Security threats within LoWPANs may be different from existing
      threat models in ad-hoc network environments.  If IEEE 802.15.4
      security is not used, Neighbor Discovery (ND) in IEEE 802.15.4
      links is susceptible to threats.  These include NS/NA spoofing,
      malicious router, default router killed, good router goes bad,
      spoofed redirect, replay attacks and remote ND DoS [RFC3756].
      However, if IEEE 802.15.4 security is used, no other protection is
      needed for ND, as long as none of the nodes becomes compromised,
      because the Corporate Intranet Model of RFC 3756 can be assumed
      [I-D.ietf-6lowpan-nd].

      Bootstrapping may also impose additional threats.  For example, a
      malicious node can obtain initial configuration information in
      order to appear as a legitimate node and then carry out various
      types of attacks.  Such a node can also keep legitimate nodes busy
      by broadcasting authentication/join requests.  One option for
      mitigating such threats is the use of mutual authentication
      schemes based on the use of pre-shared keys [refs.Ikram].

      The IEEE 802.15.4 MAC provides an AES-based security mechanism.
      Routing protocols may define how this mechanism (in conjunction
      with IP security whenever available) can be used to obtain the
      intended security, either for the routing protocol alone or in
      conjunction with the security used for the data.  Byte overhead of
      the mechanism, which depends on the security services selected,
      must be considered.  In the worst case in terms of overhead, the
      mechanism consumes 21 bytes of MAC payload.

      The IEEE 802.15.4 MAC security is typically supported by crypto
      hardware even in very simple chips that will be used in a 6LoWPAN.
      Even if the IEEE 802.15.4 MAC security mechanisms are not used,
      this crypto hardware is usually available for use by application
      code running on these chips.  A security protocol outside IEEE
      802.15.4 MAC security SHOULD therefore provide a mode of operation
      that is covered by this crypto hardware.

      IEEE 802.15.4 does not specify protection for acknowledgement
      frames.  Since the sequence numbers of data frames are sent in the
      clear, an adversary can forge an acknowledgement for each data
      frame.  This weakness can be combined with targeted jamming to
      prevent delivery of selected packets.  In consequence, IEEE
      802.15.4 acknowledgements cannot be relied upon.  In applications
      that require high security, the routing protocol must not exploit
      feedback from acknowledgements (e.g. to keep track of neighbor
      connectivity, see [R16]).






Kim, et al.               Expires May 23, 2012                 [Page 26]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


5.5.  Support of Mesh Under Forwarding

   One LoWPAN may be built as one IPv6 link.  In this case, Mesh Under
   forwarding mechanisms must be supported.  While this document
   provides general, layer-agnostic guidelines about the design of
   6LoWPAN routing , the requirements in this section are specifically
   related to L2 layer.  These requirements are directed to bodies that
   might consider working on Mesh Under routing, such as IEEE.  The
   requirements described in this subsection allow optimization and
   correct operation of routing solutions taking into account the
   specific features of the Mesh Under configuration.

   [R15] Mesh Under requires the development of a routing protocol
   operating below IP.  This protocol MUST support 16-bit short and 64-
   bit extended MAC addresses.

   [R16] In order to perform discovery and maintenance of neighbors
   (i.e., neighborhood discovery as opposed to ND-style neighbor
   discovery), LoWPAN Nodes SHOULD avoid sending separate "Hello"
   messages.  Instead, link-layer mechanisms (such as acknowledgments)
   MAY be utilized to keep track of active neighbors.

      Reception of an acknowledgement after a frame transmission may
      render unnecessary the transmission of explicit Hello messages,
      for example.  In a more general view, any frame received by a node
      may be used as an input to evaluate the connectivity between the
      sender and receiver of that frame.

   [R17] If the routing protocol functionality includes enabling IP
   multicast, then it MAY employ structure in the network for efficient
   distribution in order to minimize link layer broadcast.

5.6.  Support of Management

   When a new protocol is designed, the operational environment and
   manageability of the protocol should be considered from the start
   [RFC5706].  This subsection provides a requirement on the
   manageability of 6LoWPAN routing protocols.

   [R18] A 6LoWPAN routing protocol SHOULD be designed according to the
   guidelines for operations and management stated in [RFC5706].

      The management operations that a 6LoWPAN routing protocol
      implementation can support depend on the memory and processing
      capabilities of the 6LoWPAN devices used, which are typically
      constrained.  However, 6LoWPAN networks may benefit significantly
      from supporting 6LoWPAN routing protocol management operations
      such as configuration and performance monitoring.



Kim, et al.               Expires May 23, 2012                 [Page 27]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


      The design of 6LoWPAN routing protocols should take into account
      that, according to the Architectural Principles of the Internet
      [RFC1958], "options and parameters should be configured or
      negotiated dynamically rather than manually".  This is especially
      important for 6LoWPAN networks, which can be composed of a large
      number of devices (and, in addition, these devices may not have an
      appropriate user interface).  Therefore, parameter
      autoconfiguration is a desirable property for a 6LoWPAN routing
      protocol, although some subset of routing protocol parameters may
      allow other forms of configuration as well.

      In order to verify the correct operation of the 6LoWPAN routing
      protocol and the network itself, a 6LoWPAN routing protocol should
      allow monitoring the status and/or value of 6LoWPAN routing
      protocol parameters and data structures such as routing table
      entries.  In order to enable fault management, further monitoring
      of the 6LoWPAN routing protocol operation is needed.  For this,
      faults can be reported via error log messages.  These messages may
      contain information such as number of times a packet could not be
      sent to a valid next hop, duration of each period without
      connectivity, memory overflow and its reasons, etc.

      [RFC5706], and in particular section 3 of this document, provides
      a comprehensive guide in order to properly design the management
      solution for a 6LoWPAN routing protocol.


























Kim, et al.               Expires May 23, 2012                 [Page 28]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


6.  Security Considerations

   Security issues are described in Section 5.4.  The security
   considerations in RFC 4919 [RFC4919], RFC 4944 [RFC4944] and RFC 4593
   [RFC4593] apply as well.

   The use of wireless links renders a 6LoWPAN susceptible to attacks
   like any other wireless network.  In outdoor 6LoWPANs, the physical
   exposure of the nodes allows an adversary to capture, clone or tamper
   with these devices.  In ad-hoc 6LoWPANs that are dynamic in both
   their topology and node memberships, a static security configuration
   does not suffice.  Spoofed, altered, or replayed routing information
   might occur while multihopping could delay the detection and
   treatment of attacks.

   This specification expects that the link layer is sufficiently
   protected, either by means of physical or IP security for the
   backbone link or with MAC sublayer cryptography.  However, link-layer
   encryption and authentication may not be sufficient to provide
   confidentiality, authentication, integrity, and freshness to both
   data and routing protocol packets.  Time synchronization, self-
   organization and secure localization for multi-hop routing are also
   critical to support.

   For secure routing protocol operation, it may be necessary to
   consider authenticated broadcast (and multicast) and bidirectional
   link verification.  On the other hand, secure end-to-end data
   delivery can be assisted by the routing protocol.  For example,
   multi-path routing could be considered for increasing security to
   prevent selective forwarding.  However, the challenge is that
   6LoWPANs already have high resource constraints, so that 6LBR and
   LoWPAN nodes may require different security solutions.



















Kim, et al.               Expires May 23, 2012                 [Page 29]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


7.  IANA Considerations

   This document contains no actions for IANA.
















































Kim, et al.               Expires May 23, 2012                 [Page 30]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


8.  Acknowledgements

   The authors highly appreciate the authors of "6LoWPAN security
   analysis" document (draft-daniel-6lowpan-security-analysis-04).
   Although their security analysis work is not continuous at this
   moment, the valuable information and text of the docuement is used in
   Section 5.4 in this docuement, by advice during IESG review
   procedures.  Thanks to the work, the Section 5.4 is well improved.
   The authors also thank S. Chakrabarti who gave valuable comments for
   mesh-under requirements and A. Petrescu for significant review.









































Kim, et al.               Expires May 23, 2012                 [Page 31]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


9.  References

9.1.  Normative References

   [IEEE802.15.4]
              IEEE Computer Society, "IEEE Std. 802.15.4-2006 (as
              amended)", 2007.

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

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

9.2.  Informative References

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low Power and Lossy Networks
              (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
              October 2011.




Kim, et al.               Expires May 23, 2012                 [Page 32]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


   [I-D.ietf-karp-threats-reqs]
              Lebovitz, G., Bhatia, M., and R. White, "The Threat
              Analysis and Requirements for Cryptographic Authentication
              of Routing Protocols' Transports",
              draft-ietf-karp-threats-reqs-01 (work in progress),
              October 2010.

   [I-D.ietf-roll-protocols-survey]
              Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview
              of Existing Routing Protocols for Low Power and Lossy
              Networks", draft-ietf-roll-protocols-survey-07 (work in
              progress), April 2009.

   [RFC5556]  Touch, J. and R. Perlman, "Transparent Interconnection of
              Lots of Links (TRILL): Problem and Applicability
              Statement", RFC 5556, May 2009.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions",
              RFC 5706, November 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [refs.Chen]
              Chen, B., Muniswamy-Reddy, K., and M. Welsh, "Ad-Hoc
              Multicast Routing on Resource-Limited Sensor Nodes", 2006.

   [refs.Hill]
              Hill, J., "System Architecture for Wireless Sensor
              Networks".

   [refs.Ikram]
              Ikram, M., "A Simple Lightweight Authentic Bootstrapping
              Protocol for IPv6-based Low Rate Wireless Personal Area



Kim, et al.               Expires May 23, 2012                 [Page 33]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


              Networks (6LoWPANs)", June 2009.

   [refs.Kuhn]
              Kuhn, F., Wattenhofer, R., and A. Zollinger, "Worst-Case
              Optimal and Average-Case Efficient Ad-Hoc Geometric
              Routing", 2003.

   [refs.Latre]
              Latre, M., De Mil, P., Moerman, I., Dhoedt, B., and P.
              Demeester, "Throughput and Delay Analysis of Unslotted
              IEEE 802.15.4", May 2006.

   [refs.Lee]
              Lee, S., Belding-Royer, E., and C. Perkins, "Scalability
              Study of the Ad Hoc On-Demand Distance-Vector Routing
              Protocol", March 2003.

   [refs.Shih]
              Shih, E., "Physical Layer Driven Protocols and Algorithm
              Design for Energy-Efficient Wireless Sensor Networks",
              July 2001.

   [refs.SmartDust]
              Pister, K. and B. Boser, "Smart Dust: Wireless Networks of
              Millimeter-Scale Sensor Nodes".

   [refs.bulusu]
              Bulusu, N. and S. Jha, "Wireless Sensor Networks",
              July 2005.

   [refs.cctc]
              Lu, J., Valois, F., Dohler, M., and D. Barthel,
              "Quantifying Organization by Means of Entropy", 2008.


















Kim, et al.               Expires May 23, 2012                 [Page 34]

Internet-Draft        6LoWPAN Routing Requirements         November 2011


Authors' Addresses

   Eunsook Eunah Kim
   ETRI
   161 Gajeong-dong
   Yuseong-gu
   Daejeon  305-700
   Korea

   Phone: +82-42-860-6124
   Email: eunah.ietf@gmail.com


   Dominik Kaspar
   Simula Research Laboratory
   Martin Linges v 17
   Fornebu  1364
   Norway

   Phone: +47-6782-8223
   Email: dokaspar.ietf@gmail.com


   Carles Gomez
   Universitat Politecnica de Catalunya/i2CAT
   Escola Politecnica Superior de Castelldefels
   C/Esteve Terradas, 7
   Castelldefels  08860
   Spain

   Phone: +34-93-413-7206
   Email: carlesgo@entel.upc.edu


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Fax:   +49-421-218-7000
   Email: cabo@tzi.org








Kim, et al.               Expires May 23, 2012                 [Page 35]