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

Versions: 00 01

Network Working Group                                     S. Chakrabarti
Internet-Draft                                           Azaire Networks
Expires: September 2, 2007                                S. Daniel Park
                                                     SAMSUNG Electronics
                                                           March 1, 2007

                 LowPan Mobility Requirements and Goals

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 2, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 1]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007


   IETF LowPan working group defines IPv6 over low-power personal area
   network (IEEE 802.15.4).  Lowpan architecture allows routing to take
   place at the link layer in order to save payload overhead over the
   IEEE 802.15.4 link and thus more efficient routing for low power, low
   data-rate networks such as sensor networks.  This document discusses
   a few scenarios of mobility in LowPan network and states mobility
   requirements and goals for LowPan networks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Goals of mobility in LowPan  . . . . . . . . . . . . . . . . .  4
   3.  Requirements of mobility in LowPan . . . . . . . . . . . . . .  5
   4.  Possible Scenarios of Mobility in 6lowPan  . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 2]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

1.  Introduction

   The IPv6-over-IEEE 802.15.4 [1] document has specified IPv6 headers
   carrying over IEEE 802.15.4 network with the help of a adaptation
   layer which sits between the MAC layer and the network layer.  The
   LowPan network is characterized by low-powered, low bit-rate, short
   ranged, low cost network.  The LowPan payload capability is between
   102 bytes to 81 bytes depending on usage of link-layer security.
   Hence usage of 128bit uncompressed IPv6 address in undesirable in the
   network.  LowPan networks are typically ad-hoc in nature and several
   multihop routing algorithms such as RFC3561, RFC3626, RFC3684 may be
   partially applied to LowPan network.  However, the above mentioned
   mobile ad-hoc network protocols are designed for IP network which is
   different from the nature of LowPan network including data-rate,
   power efficiency, payload capability and routing layers.  The LowPan
   goals and requirements [2] also state that the routing packets should
   fit within a single IEEE 802.15.4 frame.

   The IPv6-over-IEEE 802.15.4 [1] document provides mesh routing
   capability at the link layer.  Yet each node is configured with IPv6
   addresses.  Thus a IEEE 802.15.4 may look like one single IPv6 subnet
   to the IP layer.  It may be an auto-configuration issue how IPv6
   addresses are configured, the mobility cases still need to consider
   IPv6 addresses and IEEE 802.15.4 MAC addresses for routing.

   In this document, we are considering mobility within a isolated
   network across different IEEE 802.15.4 Personal area networks and
   movement across different IPv6-over-IEEE 802.15.4 networks.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 3]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

2.  Goals of mobility in LowPan

   o  A lowpan node which participates in forwarding packet from its
      neighbor, may no longer be available to forward packet if it moves
      away from its neighbor's range of wireless transmission.  Thus the
      sender of the packet needs to find an alternate route if the
      forwarder node becomes unreachable.

   o  A lowpan node should be reachable by another lowpan node or a
      global network node even if it moves from one personal area
      network to another.

   o  A lowpan node or a group of lowpan nodes comprising a IEEE
      802.15.4 network may be able to keep continuous connectivity while
      moving across different personal area networks depending on the
      application requirements.

   o  Due to the nature of instability in the LowPan or sensor networks,
      the protocol design must take consideration in distributed storage
      of inforamtion rather than conventional central repository or
      server style architecture.

   o  In order to protect the resources in the low-power networks, node
      authentication and authorization may be necessary for joining the
      network.  An efficient protocol design should consider security as
      part of the features.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 4]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

3.  Requirements of mobility in LowPan

   o  A lowpan node has a IPv6 address (global or link-local) as well as
      IEEE 802.15.4 MAC address.

   o  A lowpan node in a isolated IEEE802.15.4 network that has no
      connectivity outside itself, does not require to have global IPv6
      address configuration.If the routing of packets are performed at
      the lowpan layer using M bit, then only link-local address
      configuration is sufficient.

   o  When a lowpan node moves from one personal area network(6lowpan)
      to another, it should immediately inform the new PAN co-ordinator
      about its presence.  The PAN co-ordinator through its IPv6 router
      should inform the previous IPv6 router about the new IPv6 address
      of the new node that was present in the old-lowpan network.  Thus
      it is possible that the roaming node can still talk to its
      corresponder at the old-lowpan network.

   o  A inter-6lowpan gateway protocol is needed to comunicate the new
      location (IPv6 global prefixes) of the roaming 6lowpan node which
      moves across different 6lowpan networks

   o  The original IPv6 gateway is responsible for buffering and
      forwarding packets directly destined to the moved lowpan node, if
      there is already a communication in place during the node
      movement.  If the moved lowpan node was used as a L2-forwarder at
      the previous location then it is no longer used as a forwarder for
      the old-lowpan network.  However, a moved lowpan node can continue
      being a forwarder for the same packet-path, if it moves within the
      same 6lowpan network and its reachability from the sender node
      remains the same or better.

   o  For global connectivity with the Internet, a lowpan node or a
      group of lowpan node must be addressed by a global IPv6 address.
      Since 6lowpan network assumes that there is one IPv6 router per
      6lowpan network, the IPv6 router is responsible for providing the
      global addresses to each node in the 6lowpan network.

   o  The movement of a 6lowpan node with an IPv6 address can be
      transparent to a correspondent IPv6 node external to the 6lowPan
      network, if the movement happens within the 6lowpan network, i.e.
      when the nodes IPv6 global address does not change.

   o  As with any network, the movement of a lowpan node may introduce
      security threats in the old and new LowPan Networks.  Thus,
      authentication of mobile lowpan node is required when it updates
      the movement information to the new and old IPv6 6lowpan routers

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 5]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

      or local IPv6 routing group-leaders.

   o  The lowpan nodes must be able to detect its movement from one
      wireless LowPan to another correctly.  This may require multiple
      hints from signal strength measurement to packet reception
      capacity and location or neighborhood assessment.  In addition,
      the group security key and key distributor information may be used
      as one of the attributes for movement across 6lowpan network.

   o  A 6lowpan network may be attached to a mobile network through a
      IPv6 router.  For example, in a vehicle, a few 6lowpan networks
      are connected through some Wifi access points to the operator's
      network or Internet.  The vehicle transmits data to a central
      location via Internet or operator's network.  In this case, there
      could be 2 scenarios - 1) the 6lowpan nodes are always inside the
      vehicle and they are stationary. 2) the 6lowpan nodes move and
      join/detatch different 6lowpan networks within the vehicle 3) A
      6lowpan network may step out of the vehicle and find a different
      wireless access point to talk to the Internet.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 6]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

4.  Possible Scenarios of Mobility in 6lowPan

   Mobility within a 6LowPan - It is assumed that the LowPan network is
   comprised of a single 6lowpan network.  A 6lowpan network is composed
   of one IPv6 router at the top and bunch of co-ordinators, full-
   functional devices and reduced-functional devices.  The data routing
   from one node to another node happens at the L2-layer using IEEE
   802.15.4 MAC addresses.  The global IPv6 addresses are however
   assigned by the IPv6 router and the IPv6 router is also responsible
   for Neighbor discovery [3] process.  A 6LowPan network can be a
   isolated network or it may be connected to a global network with a
   network layer gateway[3].

   Mobility across two different 6lowPan networks- A lowpan node moves
   from IEEE802.15.4 network to a mesh network.  Assume that these two
   6LowPan networks are interconnected.  Routing function takes place at
   the network-layer between the two IPv6-routers or gateways and the
   packet routing takes place at the link-layer within a 6lowpan network
   across different 6lowpan nodes.

   Mobility across LowPan and other wireless network - A multi-
   interfaced node may have IEEE802.15.4 radio for LowPan network and
   other wireless radio for communicating on the regular Internet or a
   different type of wireless network.  These devices often act as
   gateways.  A lowpan gateway can be mobile.

   Moving of a 6lowpan node from one 6lowpan network to another 6lowpan
   network across the Internet is another example of mobility across
   6LowPan networks.

   6lowpan networks may be attached to a mobile Wireless network (NEMO).
   A 6lowpan network may be reachable by a fixed entity in the Internet
   while it is moving along with the mobile network as in NEMO.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 7]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

5.  Security Considerations

   Security considerations for the mobility in LowPan networks are
   discussed in the "Requirements" section above.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 8]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

6.  IANA Considerations

   No actions are required by IANA for this document.

Chakrabarti & Daniel Park  Expires September 2, 2007            [Page 9]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

7.  Acknowledgements

   The author likes to thank Rajeev Koodli for initial discussion about
   this document.

Chakrabarti & Daniel Park  Expires September 2, 2007           [Page 10]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

8.  References

8.1.  Normative References

   [1]  Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets
        over IEEE 802.15.4 networks", draft-ietf-6lowpan-format-10.txt
        (work in progress), February 2007.

   [2]  Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
        Assumptions, Problem Statement and Goals",
        draft-ietf-6lowpan-problem-07.txt (work in progress),
        February 2007.

   [3]  Chakrabarti, S. and N. Nordmark, "6LowPan Neighbor Discovery
        Extensions", draft-chakrabarti-6lowpan-nd-03.txt (work in
        progress), March 2007.

8.2.  Informative References

   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6),
        Specification", RFC 2460, December 1998.

   [5]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [6]  IEEE Computer Society, "IEEE Std. 802.15.4-2003",  ,
        October 2003.

Chakrabarti & Daniel Park  Expires September 2, 2007           [Page 11]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

Authors' Addresses

   Samita Chakrabarti
   Azaire Networks
   3121 Jay Street, Suite 210
   Santa Clara, CA

   Email: Samita.Chakrabarti@azairenet.com

   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics.

   Email: soohong.park@samsung.com

Chakrabarti & Daniel Park  Expires September 2, 2007           [Page 12]

Internet-Draft     LowPan Mobility Requirements-Goals         March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Chakrabarti & Daniel Park  Expires September 2, 2007           [Page 13]

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