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
draft-chakrabarti-mobopts-lowpan-req-01
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 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
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.
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
USA
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
"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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chakrabarti & Daniel Park Expires September 2, 2007 [Page 13]