Hello, All,
We have submitted an updated version of 6lowpan commissioning draft to IETF.
While it is being published, please refer to the following link and the
attached draft in this mail.
http://www.ietf.org/proceedings/staging/draft-daniel-6lowpan-commissioning-01.txt
Please read the draft and provide comments in the mailing list.
Thanks,
--
Ki-Hyung Kim.
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
Seung Wha Yoo
Ajou University
San 5 Wonchun-dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 442-749
KOREA
Phone: +82 31 216 1603
Email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
Geoffrey Mulligan
Email: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
Kim, Ed., et al. Expires September 11, 2008 [Page 13]
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
