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]