Network Working Group K. Kim, Ed. Internet-Draft C. Lim Intended status: Standards Track picosNet Corp/Ajou Univ. Expires: September 11, 2008 S. Yoo Ajou University S. Park, Ed. SAMSUNG Electronics G. Mulligan March 10, 2008 Commissioning in 6LoWPAN draft-daniel-6lowpan-commissioning-01.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 September 11, 2008. Abstract The commisioning process defines the startup procedure taken by the 6LoWPAN device. This document defines the startup procedure that all kinds of devices must take to become part of the network. Kim, Ed., et al. Expires September 11, 2008 [Page 1] Internet-Draft Commissioning in 6LoWPAN March 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Resetting the device . . . . . . . . . . . . . . . . . . . 4 3.2. Scanning through channels . . . . . . . . . . . . . . . . 5 3.3. Starting a new network . . . . . . . . . . . . . . . . . . 6 3.4. Joining the network . . . . . . . . . . . . . . . . . . . 6 3.4.1. Joining the network with association . . . . . . . . . 6 3.4.2. Joining the network without association . . . . . . . 8 3.5. Setting the beacon data structure . . . . . . . . . . . . 8 4. Assigning the short address . . . . . . . . . . . . . . . . . 8 5. Obtaining IPv6 address . . . . . . . . . . . . . . . . . . . . 9 6. Configuration Parameters . . . . . . . . . . . . . . . . . . . 10 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Kim, Ed., et al. Expires September 11, 2008 [Page 2] Internet-Draft Commissioning in 6LoWPAN March 2008 1. Introduction 6LoWPAN is a low-power wireless personal area network(LoWPAN) which is comprised of the IEEE 802.15.4-2003 standard [ieee802.15.4] devices. Every device needs specific procedure to start their functioning. This procedure needs to be well defined for interoperability of devices from different vendors. This document defines the procedure taken by 6LoWPAN constituent devices when they first start operation. This procedure involves starting a new network, becoming part of existing network and obtaining IP settings. 2. Terminology Active Scan An active scan is used by an FFD to locate all coordinators transmitting beacon frames within its personal operating space, which is provided by IEEE 802.15.4. It request other devices to transmit the beacon frame. Association A IEEE 802.15.4 device can be assigned a dynamic 16 bit short address during an association operation with a neighbor device (or router) which is also called as the parent device. After getting the short address, a device can communicate with its parent or child by using only the assigned short address. Coordinator A full-function device (FFD) which is the principal controller of a 6LoWPAN. It is also called as PAN coordinator. It MAY initiate the synchronization of the entire 6LoWPAN by transmitting beacons. ED Scan An ED scan allows a device to obtain a measure of the peak energy in each requested channel, which is provided by IEEE 802.15.4. Full Function Device (FFD) A device implementing the complete protocol set of IEEE 802.15.4. It is capable of operating as a router (multi-hop packet forwarding) for its associated neighbors. Neighbor Table A table which has the information of neighbor devices in a personal operating space. Kim, Ed., et al. Expires September 11, 2008 [Page 3] Internet-Draft Commissioning in 6LoWPAN March 2008 PAN Id The 16 bit 6LoWPAN identifier which is administratively assigned to a 6LoWPAN. Passive Scan A passive scan, like an active scan, is used by an FFD to locate all coordinators transmitting beacon frames within its personal operating space, which is provided by IEEE 802.15.4. The difference is that the passive scan is a receive-only operation and does not request the beacon frame. Personal Operating Space (POS) The area within the reception range of the wireless transmission of a IEEE 802.15.4 packet. Reduced Function Device (RFD) A IEEE 802.15.4 device of 6LoWPAN which does not have the functionality of the router. That is, it can not forward IPv6 packets to the next hop device. It can only be the end device of 6LoWPAN. Short Address A 16 bit address dynamically assigned to a device from its parent. 2.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Bootstrapping Bootstrapping is defined as associating with the network and obtaining IPv6 address. Specifically, this includes the process of starting the network, associating with other nodes, obtaining the unique IPv6 address, and constructing security credentials for 6LoWPAN. 3.1. Resetting the device After the device is started, it first performed a MAC layer reset, by issuing MLME-RESET.request with the SetDefaultPIB parameter set to TRUE. Kim, Ed., et al. Expires September 11, 2008 [Page 4] Internet-Draft Commissioning in 6LoWPAN March 2008 3.2. Scanning through channels During this phase, functional supports by 802.15.4 are used for scanning channels. Adaptation Device Layer MAC | | | MLME-SCAN.request(active)| |------------------------------>| | | | | Beacon request | |------------------> | | Beacon | |<------------------ | | | MLME-SCAN.confirm | |<------------------------------| | | Active Scan Adaptation Device Layer MAC | | | MLME-SCAN.request(passive) | |------------------------------>| | | | | Beacon | |<------------------ | | | MLME-SCAN.confirm | |<------------------------------| | | Passive Scan For getting the information of other devices within POS, the device should perform a scan across a specified list of channels which is defined as CHANNEL_LIST for SCAN_DURATION time. The device can use either an active scan or a passive scan. During scanning procedure, the device receive beacon frames from other devices. The beacon frame contains the information about the device sending it, which is used for determine whether a device is 6LoWPAN device or not. If the device which send the beacon frame is distingushed as the 6LoWPAN device, its information should be stored in the neighbor table. Kim, Ed., et al. Expires September 11, 2008 [Page 5] Internet-Draft Commissioning in 6LoWPAN March 2008 3.3. Starting a new network A node which starts a new network may become the coordinator. Which devices become the coordinator depends on the configuration of the device and the state of existing networks. Prior to starting a new network, the device first perform a scan for locating the PAN within its POS. Detailed procedure of a scan is described in Section 4. The device should select a channel with the least number of networks, preferrably selecting a channel with no network if possible. On this step, The device may use an ED scan to select a channel which has less channel usage. After selecting a channel for a new network, the device shall select a PAN Id which is unique among PANs within its POS. If a node can't find suitable PAN ID, it may retry this procedure after START_RETRY_TIME. The algorithm for selecting a suitable PAN Id is TBD. The node which start a new network shall set the network's superframe order and beacon order to SUPERFRAME_ORDER and BEACON_ORDER respectively. After all procedure is done, a node shall excute MAC start primitive and start to act as the FFD node. Adaptation FFD Layer MAC | | | MLME-START.request | |------------------------->| | | | | Beacon frame | |----------------> | | | MLME-START.confirm | |<-------------------------| | | 3.4. Joining the network 3.4.1. Joining the network with association Kim, Ed., et al. Expires September 11, 2008 [Page 6] Internet-Draft Commissioning in 6LoWPAN March 2008 Device Device Adaptation MAC Layer | | | MLME-ASSOCIATE.request | |---------------------------------->| | | association request | |----------------------------> | | | | association response | |<---------------------------- | MLME-ASSOCIATE.confirm | |<----------------------------------| | | Coordinator Coordinator MAC Adaptation Layer | | association request | | ------------------------>| | | MLME-ASSOCIATE.indication | |---------------------------------->| | | | MLME-ASSOCIATE.response | |<----------------------------------| | | association response | | <-------------------------| | | | To join the network, the device first performs the scanning for discoverying the PAN within its POS. Detailed procedure of a scan is described in Section 4. On completion of scan, the device selects the network it wishes to join from the scanning result. It then finds the device which corresponds to that network in its neighbor table and it requests to associate using MAC primitive to that particular device. If the device couldn't success to associate with a device, it may retry the association after ASSOCIATION_RETRY_TIME. And if the device failed to associate with all devices which is discovered, it may retry the scanning procedure which is described in Section 3.2 after JOIN_RETRY_TIME. The algorithm for selecting a device it wishes to associate among devices in the network is TBD. Kim, Ed., et al. Expires September 11, 2008 [Page 7] Internet-Draft Commissioning in 6LoWPAN March 2008 3.4.2. Joining the network without association The device doesn't need to associate with other devices to become part of the network. The non-associated device, however, must use the 64-bit extended address to communicate. In this case, the device should perform scanning periodically since devices aren't bound to each other strongly. Detailed procedure of a scan is described in Section 4. 3.5. Setting the beacon data structure After associating with the network, The device should set its beacon data structure, which is attached to the beacon frame. A beacon frame of 802.15.4 MAC has the beacon payload fields which have variable length. The beacon payload can be set by the upperlayer. The beacon data structure is as follows. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | Product ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- EUI-64 Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor ID: Contains the Vendor's unique ID Product ID: Contains the Product's unique ID EUI-64 Address: Contains the EUI-64 address of the sender. This beacon data structure shall be contained in MAC beacon frame. The device which received the beacon may use the information of beacon data structure for verifying the same product and the EUI-64 address. 4. Assigning the short address During association procedure, every device except the coordinator is given its short address from the parent device which is being requested to associate. The coordinator assigns its short address after selecting a PAN ID by itself. The short address must be unique Kim, Ed., et al. Expires September 11, 2008 [Page 8] Internet-Draft Commissioning in 6LoWPAN March 2008 in a network and may be given by a distributed way. The specific algorithm for assigning the short address is TBD. 5. Obtaining IPv6 address The IPv6 interface identifier of a device can be obtained as described in Section 6 of [rfc4944]. After having a unique IPv6 interface identifier, the device begins to obtain an IPv6 address prefix. The IPv6 address prefix for a particular 6LoWPAN is stored by the IPv6 router in the 6LoWPAN. ICMPv6 is used to share these parameters. Routers in 6LoWPAN are supposed to broadcast Router Advertisements(RA) messages periodically. The RA message must contain the prefix option which can be used in the 6LoWPAN. Devices wish to obtain IPv6 address prefix may wait for an RA message until RA_WAIT_TIME elapsed. After that, if no RA message is received, they may broadcast Router Solicitation(RS) message for requesting the RA message. The RS and RA messages can have additional option fields as described in [rfc4861]. Source/Target link-layer address option field should contain the EUI-64 address or the combined address with PAN ID and 16bit short address of the source or target device as below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- EUI-64 Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kim, Ed., et al. Expires September 11, 2008 [Page 9] Internet-Draft Commissioning in 6LoWPAN March 2008 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Short Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source/Target Link-layer Address option field Multiple IPv6 routers could form a single or multiple 6lowpan(s). If there are multiple routers in a 6LoWPAN, the device should consider which one is to be selected as a default router. One possible way of selection is to compare the hop counts traveled of the RA message of each router. The detailed algorithm for the selection is TBD. 6. Configuration Parameters This section gives default values for some important parameters associated with the 6LoWPAN commissioning protocol. A particular node may wish to change certain of the parameters. Parameter Name Value ---------------------- ----- CHANNEL_LIST 0xFFFF800 SCAN_DURATION 3 SUPERFRAME_ORDER 15 BEACON_ORDER 15 START_RETRY_TIME 1000 msec JOIN_RETRY_TIME 4000 msec ASSOCIATION_RETRY_TIME 4000 msec 7. IANA Consideration TBD. 8. Security Considerations IEEE 802.15.4 devices is required to support AES link-layer security. MAC layer also provides all keying material necessary to provide the security services. Kim, Ed., et al. Expires September 11, 2008 [Page 10] Internet-Draft Commissioning in 6LoWPAN March 2008 It isn't defined, however, when security shall be used especially combining with bootstrapping. After the device start and join the network, security services such as key management and device authentication should be done automatically. Detailed algorithm for security on bootstrapping is TBD. 9. Acknowledgments N/A 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006". 10.2. Informative References [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Authors' Addresses Ki-Hyung Kim (editor) picosNet Corp/Ajou Univ. San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 Email: kkim86@picosnet.com Kim, Ed., et al. Expires September 11, 2008 [Page 11] Internet-Draft Commissioning in 6LoWPAN March 2008 Chae-Seong Lim picosNet Corp/Ajou Univ. San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 216 1765 Email: crimsuni@gmail.com Seung Wha Yoo Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 216 1603 Email: swyoo@ajou.ac.kr Soohong Daniel Park (editor) SAMSUNG Electronics Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong Yeongtong-gu, Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Geoffrey Mulligan Email: geoff@mulligan.com Kim, Ed., et al. Expires September 11, 2008 [Page 12] Internet-Draft Commissioning in 6LoWPAN March 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. Kim, Ed., et al. Expires September 11, 2008 [Page 13]