[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
6lowpan                                                      G. Mulligan
Internet-Draft                                                    Proto6
Intended status: Standards Track                             C. Williams
Expires: January 9, 2009                                          D. Huo
                                                                 ZTE USA
                                                            July 8, 2008


                  Mobility Considerations for 6LoWPAN
                   draft-williams-6lowpan-mob-00.txt

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 9, 2009.
















Mulligan, et al.         Expires January 9, 2009                [Page 1]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


Abstract

   There has been discussion recently within the 6LoWPAN community
   regarding mobile usage scenarios.  Mobility considerations and
   analysis is required to ensure proper performance for the mobile
   usage cases.  Also, mobility in 6LoWPAN sensor networks may present
   unique challenges to the 6LoWPAN architecture.  Hence it is best to
   have mobility as a consideration upfront rather than an after thought
   in the development of 6LoWPAN milestones.  This document provides a
   mobility perspective to the 6LoWPAN sensor network architecture.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Extensions of the PAN Framework  . . . . . . . . . . . . .  6
     3.2.  Global reachability and changing connectivity  . . . . . .  8
   4.  Changing connectivity points of attachments  . . . . . . . . . 10
   5.  Security of the mobile access network  . . . . . . . . . . . . 12
     5.1.  Mobile security for the extended PAN . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19





















Mulligan, et al.         Expires January 9, 2009                [Page 2]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


1.  Introduction

   The IETF 6LoWPAN working group was formed in 2004 to address the
   challenge of enabling wireless IPv6 communication over the newly
   standardized IEEE 802.15.4 low-power radio for devices with limited
   space, power and memory, such as sensor nodes.  IEEE 802.15.4 radio
   links, coupled with the interoperability and ubiquity of IP, will
   lead to exciting new deployment scenarios for these low-power
   networks.  Sensor wireless networks will be integrated into wired
   and/or wireless fixed infrastructure.  The integration of these
   sensor networks with the Internet and wireless infrastructure
   networks increases the network capacity, coverage area and
   application domains.  Such an integration requires that 6LoWPAN
   networks handle mobility scenarios.

   Mobility in 6LoWPAN networks is being examined because users that are
   interested in sensor data will not always be stationary.  In
   addition, mobile users will need to inject a sensor query into the
   6LoWPAN network while they are mobile.  Mobile users will also need
   to retrieve a sensor response from the 6LoWPAN network while they are
   mobile.

   It has also been shown that sensor mobility can be exploited to
   compensate for the lack of sensors and improve network coverage.
   [MOBCOVERAGE] It has also been shown that mobility helps with
   localization requirements by wireless sensor applications that depend
   on nodes accurately determining their locations [MOBLOCAL].
   Moreover, there has been a desire to deploy sensors mounted on mobile
   platforms such as automobiles and planes.

   Mobility will also play a role in the future interconnection
   framework for 6LoWPAN networks as it is expected that internetworking
   will not necessarily be limited to a way to transport information
   from and to remote hosts.  The foreseen degree of integration between
   sensor networks may reach upper levels of the protocol stack, where
   one network may offer services to others (including communication
   services).  In such a setting, even 6LoWPAN sensor network components
   may be heterogeneous, consisting of sensors with varied
   functionalities, capabilities and interconnection requirements.
   Currently, wireless sensor networks are beginning to be deployed at
   an accelerated pace.  It is not unreasonable to expect that in the
   near future, many segments of the world will be covered with wireless
   sensor networks that will be accessible via the Internet.
   Integration of wireless sensor networks with wireless local area
   networks and the Internet, while being important, comes with
   connectivity and security issues.

   What the authors have concluded through their extensive prototyping



Mulligan, et al.         Expires January 9, 2009                [Page 3]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   and deployment, it is best to have mobility as a consideration
   upfront rather than an after thought in the development of 6LoWPAN
   milestones.  This document provides a mobility perspective to the
   6LoWPAN sensor network architecture.















































Mulligan, et al.         Expires January 9, 2009                [Page 4]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


2.  Terminology

   See RFC3753 [RFC3753]for mobility terminology used in this document.
















































Mulligan, et al.         Expires January 9, 2009                [Page 5]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


3.  Framework

3.1.  Extensions of the PAN Framework

   In practical deployment scenarios, 6LowPAN networks may not be
   isolated independent PANs.  A personal network will be logical
   networks, defined by appropriate security associations.  In practice
   personal networks will have potential huge geographical and
   topological span.  Personal networks will consists of both ad-hoc and
   infrastructure networks.  It will be user centric with the PAN (i.e.,
   Core PAN) as the central entity.  An extension of the PAN framework
   is provided in the diagram below.







































Mulligan, et al.         Expires January 9, 2009                [Page 6]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   Extensions of the PAN Concept:


                                  (Personal Network)

     Local Foreign Devices                       Remote personal Devices
            |                                              |       |
            |                                              |       |
            |                                   ***********|*******|**
            |                                   *  +-------|-----+ | *
                                                *  |       V     | | *
  **********|**********                         *  | Home Network| | *
  *  +------|----+    *               ***********  +-------------+ | *
  *  |Smart |Bldg |   *               *             /              | *
  *  |    0 V     |   *               *            /   ************|**
  *  |       0    |   *               *           /    *           |
  *  +-----------+    *  +------------*----------------*----+      |
  *                   *  |            *                *    |      |
  *      |            *****************                ************|***
  *      |               |  Interconnecting Structure       |      |  *
  *       \              |(Internet, WLAN, 3G, Ad-hoc, etc) | +----|-+*
  *        |             |                                  | |    V |*
  *        |             |                                  |-|Corp  |*
  *        |             | ******                           | Network|*
  *                      +-*----*---------------------------+ +------+*
  *                        *    *                                 *****
  *      (user)        *****    *      ___                        *
  *   +-------------+  *        *        /___                     *****
  *   |  Core PAN   |  *        *  +-----------+     +--------------+ *
  *   |        0    |  *_____   *  |    PAN    |__   |Vehicular Area| *
  *   |    0     0  |  *    /___*__|     0     | /__ |   Network    | *
  *   |        0    |  *        *  |   0    0  |     |   0          | *
  *   +-------------+  *        *  +--------\--+     +/-------------+ *
  *                    *        *            \       /                *
  **********************        **************\*****/******************
                                               \   /
                                                \ /
                                                 |
                                        Remote Foreign Devices

                                 Figure 1

   In this extended PAN framework a diverse personal network is
   presented.  The illustration local foreign devices in a smart
   building which are only accessed through the user's core PAN.  No
   direct permanent connectivity is provided to these devices.  The
   diagram also illustrates a PAN connected to a 3G network as well as a
   vehicular area network of sensors.  Individual sensor nodes from the



Mulligan, et al.         Expires January 9, 2009                [Page 7]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   PAN and Vehicular Area network may join and change PANs.  Remote
   foreign devices may be accessed either by the Core PAN directly
   connecting to these ad-hoc networks or through the interconnecting
   structure.  The corporate and home network are connected to the
   Interconnecting structure and may have remote personal devices.  The
   extension of the PAN framework presented shows a diverse and huge
   geographical and topological span with a mobility presence various
   aspects of the architecture.

3.2.  Global reachability and changing connectivity

   6LoWPAN networks may require to be fully integrated into a dynamic
   mobile heterogeneous framework for ensuring global reachability to
   the individual 6LoWPAN nodes

   Sensor networks share several characteristics of ad-hoc scenarios in
   that sensor nodes are capable of receiving and forwarding packets to
   their peers.  However, tiny sensor devices may have more stringent
   processing power, memory and energy constraints than other types of
   ad hoc networks.  These constraints generally imply the need for a
   hierarchical ad-hoc network structure in which low-tier sensor nodes
   connect to the Internet via one or more levels of gateway devices.
   In this draft, we assume that each autonomous network of wireless
   sensor devices will have one gateway device.  This gateway device is
   responsible for media conversion (from 802.15.4 to another link layer
   technology, such as 802.11, and vice versa) and for route advertising
   to the outside world, which may be a wireless local area network
   connected to the Internet.

   There will be deployment scenarios where 6LoWPAN networks have
   persistent connectivity to the outside world via its gateway device.
   At the same time, there may be deployment scenarios that require that
   a 6LoWPAN network change its point of attachment to the outside world
   from an IP perspective.  This may occur, for example, when a sensor
   network is part of a moving vehicle which may roam from one wireless
   local area network to another wireless local area network with
   different IP network prefixes.  By the same token, an autonomous
   sensor network may be deployed in a location with no wireless (or
   wired) local area networks.  In this case, its connectivity to the
   outside world, when it exists, will be intermittent.  Also, the
   intermittent connectivity to the Internet may have different
   characteristics each time they occur.  For example, connectivity of
   the 6LoWPAN network to the internet may be realized via an agent
   (e.g., a vehicle) which features a satellite interface.  At different
   points in time, different agents may provide connectivity functions;
   in which case the point of attachment of the sensor network may
   correspond to a different IP address prefix.  Note that the two
   scenarios depicted above are equivalent from an IP connectivity point



Mulligan, et al.         Expires January 9, 2009                [Page 8]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   of view.  In the first scenario, the sensor network moves from one
   access network to another.  In the second scenario, agents with
   different IP addresses provide access functions to a stationary
   sensor network.  In either case, the IP address of the point of
   attachment will change over time.

   Here, the requirement is to provide global reachability to the
   6LoWPAN nodes no matter where the correspondent peers are located,
   and no matter what their point of attachment is.  The 6LoWPAN nodes
   must still be reachable with their originally prescribed IPv6
   addresses.








































Mulligan, et al.         Expires January 9, 2009                [Page 9]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


4.  Changing connectivity points of attachments

   Mobility is a fundamental characteristic of a wireless network with
   mobile users, and it is therefore anticipated that future networks
   will provide mobility support as an integrated and ubiquitous
   service.  Mobility scenarios anticipated in future networks include
   simple end-user migration from one subnetwork to another (as in
   cellular or WLAN hot-spot services), as well as more complex mobility
   patterns involving movement of radio routers and sensor network
   clusters.  Collections of sensor networks must be reachable as they
   move across different wireless domains.  Scalable and accurate
   indirection schemes need to be devised to allow for this
   functionality.

   Mobile IPv6 network mobility (NEMO) [RFC3963] defines a process that
   enables Mobile Networks to attach to different points in the
   Internet.  The protocol is an extension of Mobile IPv6 and allows
   session continuity for every node in the Mobile Network as the
   network moves.  Use of NEMO will enable all 6LoWPAN nodes to be
   accessible, no matter what the current point of attachment to the
   wide area IP network is.






























Mulligan, et al.         Expires January 9, 2009               [Page 10]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   Diagram of NEMO and 6LoWPAN integration is provided.  [RFC4944] ,
   e.g.,


                               (Nodes in the 6LoWPAN network)
                                  *   *   *  ...  *  *  *

                                        6LoWPAN
                                        network
                                           |
                                           |
                                     +-------------+
                                     | NEMO Client |
                                     +-------------+
                                           |
                                           |
                                 +--------------------+
                                 |Access Network (AR) |
                                 +--------------------+
                                           |
                                 +-------------------+
                                 |     Internet      |
                                 +-------------------+
                                            |
                                            |
                                     +---------------+
                                     | Correspondent |
                                     | Node          |
                                     +---------------+




                                 Figure 2

   The NEMO client integration enables the sensor application residing
   on some correspondent node provides global reachability to the
   6LoWPAN nodes even when the access network for the 6LoWPAN network
   changes.












Mulligan, et al.         Expires January 9, 2009               [Page 11]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


5.  Security of the mobile access network

   6LoWPAN networks may be deployed remotely in non-traditional
   scenarios.  Access networks for these 6LoWPAN networks may be
   intermittently available, and their IP address prefixes may change
   over time.  This means that the IP layer has new requirements to be
   able to provide access to these 6LoWPAN networks via changing access
   networks and to do so in a secure manner.

5.1.  Mobile security for the extended PAN

   IPv6 nodes use the Neighbor Discovery protocol (ND) [RFC2461] to
   discover other nodes on the link, to determine the link-layer
   addresses of other nodes on the link, to find routers, and to
   maintain reachability information about the paths to active
   neighbors.  If proper authentication mechanisms are not in place,
   straight use ND in sensor networks may introduce security
   vulnerabilities.  The IETF has created the Secure Neighbor Discovery
   Protocol (SeND) [RFC3971] to provide authentication services for the
   ND.  SeND may be used as a solution between the NEMO client residing
   in the Sensor network and the access network which will have a SeND
   service for providing authenticated NEMO autoconfiguration.  In this
   solution, NEMO with SeND may provide a means by which the access
   network is properly authorized to connect to the sensor network.



























Mulligan, et al.         Expires January 9, 2009               [Page 12]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


   Diagram of NEMO, SEND and 6LoWPAN integration is provided.  [RFC3971]
   , e.g.,


                               (Nodes in the 6LoWPAN network)
                                  *   *   *  ...  *  *  *


                                        6LoWPAN
                                        network
                                           |
                                           |
                                     +---------+
                                     | NEMO &  |
                                     | SEND    |
                                     +---------+
                                           |
                                           |
                                 +--------------------+
                                 |Access Network (AR) |
                                 | With SEND          |
                                 +--------------------+
                                           |
                                 +-------------------+
                                 |     Internet      |
                                 +-------------------+
                                            |
                                            |
                                     +---------------+
                                     | Correspondent |
                                     | Node          |
                                     +---------------+




                                 Figure 3

   Authentication process specified in SeND may involve the use of
   server infrastructure for certificate management purposes.  It may be
   impractical to have a server infrastructure in place for
   authentication in the deployment scenarios discussed in this draft.
   Therefore, the Cryptographically Generated Addresses (CGA) [RFC3972]
   option of SeND may be a useful tool for 6LoWPAN networks in providing
   authentication services.






Mulligan, et al.         Expires January 9, 2009               [Page 13]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


6.  Security Considerations

   Security assumptions for stationary 6LoWPAN networks are inadequate
   for scenarios whereby mobility is introduced.  Mobile users injecting
   sensor queries into the 6LoWPAN network while they are mobile pose
   new security considerations.  This is also true when mobile users are
   retrieving sensor responses from the 6LoWPAN network while they are
   mobile.  Privacy and authentication is also an area for mobile
   security analysis.  For example, privacy between the 6LoWPAN network
   point of attachment and the local area access network may be
   established using IPsec.  More security analysis is required.








































Mulligan, et al.         Expires January 9, 2009               [Page 14]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


7.  Conclusion

   Practical deployment scenarios require mobility of both individual
   sensor nodes but also connectivity points for the PANs.  Mobility as
   an architectural consideration for 6LowPAN must be consider upfront
   rather than an after thought in the development of 6LoWPAN
   milestones.  Finally, techniques developed for other mobile networks
   may not be applicable in all usage cases, as in these networks power
   conservation is not a requirement.










































Mulligan, et al.         Expires January 9, 2009               [Page 15]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


8.  Acknowledgement

   Acknowledgement of Derya Cansever for his input and contributions to
   initial discussion on mobility for sensors.















































Mulligan, et al.         Expires January 9, 2009               [Page 16]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


9.  References

9.1.  Normative references

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

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

9.2.  Informative References

   [MOBCOVERAGE]
              Liu, B., Brass, P., Dousse, O., Nain, P., and D. Towsley,
              "Mobility Improves Coverage of Sensor Networks", Mobihoc
              2005, Proceedings of MobiHoc 2005, May 2005.

   [MOBLOCAL]
              Hu, L. and D. Evans, "Localization for Mobile Sensor
              Networks", MobiCom 2004, Tenth Annual International
              Conference on Mobile Computing and Networking,
              September 2004.














Mulligan, et al.         Expires January 9, 2009               [Page 17]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


Authors' Addresses

   Geoff Mulligan
   Proto6
   Consultant
   Colarodo Springs, CO 80901
   USA

   Phone: 719.593.2992
   Email: geoff@proto6.com


   Carl Williams
   ZTE USA
   Consultant
   Palo Alto, CA 94306
   USA

   Phone: +1.650.279.5903
   Email: carlw@mcsr-labs.org


   David Huo
   ZTE USA
   33 Wood Ave S
   Metuchen, NJ 08840
   USA

   Phone: +1.732.632.9880
   Email: david.huo@zteusa.com





















Mulligan, et al.         Expires January 9, 2009               [Page 18]


Internet-Draft     Mobility Considerations for 6LoWPAN         July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.

Acknowledgement

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






Mulligan, et al.         Expires January 9, 2009               [Page 19]