Network Working Group S. Chakrabarti
Internet-Draft Sun Microsystems, Inc.
Expires: January 7, 2006 July 6, 2005
LowPan Mobility Requirements and Goals
draft-chakrabarti-mobopts-lowpan-req-00
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 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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.
Chakrabarti Expires January 7, 2006 [Page 1]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
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 LowPan . . . . . . . . . . . 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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Chakrabarti Expires January 7, 2006 [Page 2]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
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 Expires January 7, 2006 [Page 3]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
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 Expires January 7, 2006 [Page 4]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
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 to
another, it should immediately inform the new PAN co-ordinator
about its presence. The mobile lowpan node should also let its
original PAN co-ordinator know that it has moved to a new location
under the new co-ordinator.
o The original co-ordinator is responsible for buffering and
forwarding packets directly destined to the moved lowpan node. If
a pakcet uses the moved lowpan node as a forwarder at the previous
location then, the orginal co-ordinator does not forward packet to
the new location of the lowpan node except when the lowpan node
moves but stays within the same PAN and its reachability
characterstics from the original co-rdinator has improved or
remained unchanged;instead the original co-ordinator is
responsible for finding an alternative next hop for forwarding.
o For global connectivity with the Internet, a lowpan node or a
group of lowpan node may be addressed by a global IPv6 address. A
group of lowpan node may be identified by the IPv6 address of
their group-leader or co-ordinator's IPv6 address. In this case,
it's the group-leader's responsibility to pass the information to
the group where each member of the group may or may not have
individualIPv6 addresses due to their nature of low capability of
resources.
o The movement of a lowpan node with an IPv6 address can be
transparent to the correspondent IPv6 node outside the LowPan
network, if the IPv6 address of the lowpan node is not dependent
on LowPan link-layer network topology and the movement happens
only within a realm of LowPan network.
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 co-ordinators or local
routing group-leaders.
Chakrabarti Expires January 7, 2006 [Page 5]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
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.
Chakrabarti Expires January 7, 2006 [Page 6]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
4. Possible Scenarios of Mobility in LowPan
Mobility within a LowPan - It is assumed that the LowPan network is
comprised of many personal area networks. However, the routing
happens at the L2 layer using IEEE 802.15.4 addresses. A node can
move from one personal network to another. One personal area network
is identified by the IEEE 802.15.4 PAN id and co-ordinator or group-
leader characteristics. A LowPan network can be a isolated network
or it may be connected to a global network with a network layer
gateway.
Mobility across two different LowPan networks- A lowpan node moves
from IEEE802.15.4 star network to a mesh network. Assume that these
two LowPan networks are interconnected. Routing function takes place
at the link-layer.
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 lowpan node from one lowpan network to another lowpan
network across the Internet is another example of mobility across
LowPan networks.
Chakrabarti Expires January 7, 2006 [Page 7]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
5. Security Considerations
Security considerations for the mobility in LowPan networks are
discussed in the "Requirements" section above.
Chakrabarti Expires January 7, 2006 [Page 8]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
6. IANA Considerations
No actions are required by IANA for this document.
Chakrabarti Expires January 7, 2006 [Page 9]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
7. Acknowledgements
The author likes to thank Rajeev Koodli for initial discussion about
this document.
Chakrabarti Expires January 7, 2006 [Page 10]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
8. References
8.1 Normative References
[1] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets
over IEEE 802.15.4 networks",
draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt (work in
progress), February 2005.
[2] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals",
draft-kushalnagar-lowpan-goals-assumptions-00.txt (work in
progress), February 2005.
8.2 Informative References
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6),
Specification", RFC 2460, December 1998.
[4] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[5] IEEE Computer Society, "IEEE Std. 802.15.4-2003", ,
October 2003.
Author's Address
Samita Chakrabarti
Sun Microsystems, Inc.
16 Network Circle
Menlo Park, CA 95024
USA
Email: Samita.Chakrabarti@Sun.COM
Chakrabarti Expires January 7, 2006 [Page 11]
Internet-Draft LowPan Mobility Requirements-Goals July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chakrabarti Expires January 7, 2006 [Page 12]