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]