Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-mariager-6lowpan-v6over-dect-ule-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Peter B. Mariager , Jens T. Petersen | ||
| Last updated | 2011-10-31 (Latest revision 2011-04-26) | ||
| Replaced by | draft-ietf-6lo-dect-ule, RFC 8105 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mariager-6lowpan-v6over-dect-ule-01
6LoWPAN Peter B. Mariager, Ed.
Internet-Draft Jens T. Petersen
Intended status: Informational RTX A/S
Expires: May 3, 2012 October 31, 2011
Transmission of IPv6 Packets over DECT Ultra Low Energy
draft-mariager-6lowpan-v6over-dect-ule-01
Abstract
DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI.
The DECT air interface technology has been used world-wide in
communication devices for more than 15 years, primarily carrying
voice for cordless telephony but has also been deployed for data
centric services.
The DECT Ultra Low Energy is a recent addition to the DECT interface
primarily intended for low-bandwidth, low-power applications such as
sensor devices, smart meters, home automation etc. As the DECT Ultra
Low Energy interface inherits many of the capabilities from DECT, it
benefits from long range, interference free operation, world wide
reserved frequency band, low silicon prices and maturity. There is
an added value in the ability to communicate with IPv6 over DECT ULE.
This document describes how IPv6 is transported over DECT ULE using
6LoWPAN techniques.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 3, 2012.
Copyright Notice
Mariager & Petersen Expires May 3, 2012 [Page 1]
Internet-Draft IPv6 over DECT ULE October 2011
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 6
5. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. IPv6 Address Configuration . . . . . . . . . . . . . . . . . . 7
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . . 7
8. Unicast and Multicast address mapping . . . . . . . . . . . . . 8
9. Header Compression . . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
11. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
14. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
15. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Mariager & Petersen Expires May 3, 2012 [Page 2]
Internet-Draft IPv6 over DECT ULE October 2011
1. Introduction
DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface
technology building on the key fundamentals of traditional DECT /
CAT-iq but with specific changes to significantly reduce the power
consumption on the expense of data throughput. DECT ULE devices with
requirements to power consumption will operate on special power
optimized silicon, but can connect to a DECT Gateway supporting
traditional DECT / CAT-iq for cordless telephony and data as well as
the ULE extensions. DECT terminology operates with two major role
definitions: The Portable Part (PP) is the power constrained device,
while the Fixed Part (FP) is the Gateway or base station. This FP
may be connected to the internet. An example of a use case for DECT
ULE is a home security sensor transmitting small amounts of data (few
bytes) at periodic intervals through the FP, but is able to wake up
upon an external event (burglar) and communicate with the FP.
Another example incorporating both DECT ULE as well as traditional
CAT-iq telephony is an elderly pendant (broche) which can transmit
periodic status messages to a care provider using very little
battery, but in the event of urgency, the elderly person can
establish a voice connection through the pendant to an alarm service.
It is expected that DECT ULE will be integrated into many residential
gateways, as many of these already implements DECT CAT-iq for
cordless telephony. DECT ULE can be added as a software option for
the FP. It is desirable to consider IPv6 for DECT ULE devices due to
the large address space and well-known infrastructure. This document
describes how IPv6 is used on DECT ULE links to optimize power while
maintaining the many benefits of IPv6 transmission. [RFC4944]
specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has
in many ways similar characteristics of IEEE 802.15.4, but also
differences. Many of the mechanisms defined in [RFC4944] can be
applied to the transmission of IPv6 on DECT ULE links.
This document specifies how to map IPv6 over DECT ULE inspired by
RFC4944
1.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].
1.2. Terms Used
PP: DECT Portable Part, typically the sensor node
FP: DECT Fixed Part, the gateway
Mariager & Petersen Expires May 3, 2012 [Page 3]
Internet-Draft IPv6 over DECT ULE October 2011
LLME: Lower Layer Management Entity
NWK: Network
2. The DECT ULE Protocol Stack
The DECT ULE protocol stack consists of the PHY layer operating at
frequencies in the 1800 - 1920 MHz frequency band depending on the
region and uses a symbol rate of 1.152 Mbps.
In its generic network topology, DECT is defined as a cellular
network technology. However, the most common configuration is a star
network with a single FP defining the network with a number of PP
attached. The MAC layer must support both traditional DECT as this
is used for services like discovery, pairing, security features etc.
All these features have been reused from DECT.
The DECT ULE device can then switch to the ULE mode of operation,
utilizing the new ULE MAC layer features. The DECT ULE Data Link
Control (DLC) provides multiplexing as well as segmentation and re-
assembly for larger packets from layers above. The DECT ULE layer
should also implement per-message authentication and encryption.
In general, communication sessions can be initiated from both FP and
PP side. Depending of power down modes employed in the PP, latency
may occur when initiating sessions from FP side. MAC layer
communication can either take place using connection less packet
transfer with low overhead for short sessions or take place using
connection oriented bearers including media reservation. The MAC
layer autonomously selects the radio spectrum positions that are
available within the band and can rearrange these to avoid
interference.
The DECT ULE device will incorporate an Application Programmers
Interface (API) as well as common elements known as Generic Access
Profile (GAP) for enrolling into the network.
Mariager & Petersen Expires May 3, 2012 [Page 4]
Internet-Draft IPv6 over DECT ULE October 2011
+----------------------------------------+
| Applications |
+----------------------------------------+
| Generic Access Profile | ULE Profile |
+----------------------------------------+
| DECT/Service API | ULE Data API |
+--------------------+-------------------+
| LLME | NWK | |
+--------------------+-------------------+
| DECT DLC | DECT ULE DLC |
+--------------------+-------------------+
| MAC Layer |
+--------------------+-------------------+
| Physical Layer |
+--------------------+-------------------+
Figure 1: DECT ULE Protocol Stack
The DLC layer layer has to provide a reliable channel, either
directly or through MAC layer service to the higher layers. It is
expected that the ULE 6LoWPAN adaptation layer can run directly on
this DLC layer. Figure 2 illustrates IPv6 over DECT ULE stack.
Constrained Application Protocol (CoAP) is an application protocol
specifically designed for resource constrained environments. CoAP
could be run on top of IPv6 supporting requests from the server and
requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed
Part.
Alternatively, the use of HTTP light, as defined for CAT-iq v3 can be
considered.
Mariager & Petersen Expires May 3, 2012 [Page 5]
Internet-Draft IPv6 over DECT ULE October 2011
+-------------------+
| Applications |
+-------------------+
| CoAP/HTTP |
+-------------------+
|IPv6 adaption layer|
+-------------------+
| DECT ULE DLC |
+-------------------+
| DECT ULE MAC |
+-------------------+
| DECT ULE PHY |
+-------------------+
Figure 2: IPv6 over DECT ULE Stack
3. Requirements
DECT ULE technology sets strict requirements for low power
consumption and thus limits the allowed protocol overhead. 6LoWPAN
standard [RFC4944] provides useful generic functionality like header
compression, link-local IPv6 addresses, Neighbor Discovery and
stateless IP-address autoconfiguration for reducing the overhead in
802.15.4 networks. This functionality can be partly applied to DECT
ULE.
4. Addressing Model
Each DECT PP is assigned an <IPEI> (International Portable Equipment
Identity) during manufacturing. This identity has the size of 40
bits and is unique for the PP and will be used to constitute the MAC
address.
When bound to the FP, a PP is assigned a 20 bit TPUI (Temporary
Portable User Identity) which is unique within the FP. This TPUI is
used for addressing in messages between FP and PP.
Each DECT FP is assigned a <RFPI> (Radio Fixed Part Identity) during
manufacturing. This identity has the size of 40 bits and is unique
for a FP and will be used to constitute the PAN identity.
Mariager & Petersen Expires May 3, 2012 [Page 6]
Internet-Draft IPv6 over DECT ULE October 2011
5. MTU Considerations
Generally the DECT ULE PP generate data that fits into one MAC Layer
packet (40 bytes or optionally 80 bytes) that is transferred to the
FP periodically, depending on application. IP data packets may be
much larger and hence MTU size should be the size of the IP data
packet.
Larger IP packets can be transferred with the Segmentation and
reassembly (SAR) feature of the DLC Layer. If an implementation
cannot support the larger MTU size (due to cost) then SAR needs to be
supported at upper layers.
The SAR feature of [RFC4944] section 5 could also be considered.
It is expected that the LOWPAN_IPHC packet will fulfill all the
requirements for header compression without spending unnecessary
overhead for mesh addressing.
It is important to realize that the support of larger packets will be
on the expense of battery life, as a large packet will be fragmented
into several or many MAC layer packets, each consuming power to
transmit / receive.
6. IPv6 Address Configuration
StateLess AutoConfiguration (SLAC) and other means to configure an
address on a ULE device.
Neighbor Discovery Optimization for Low-power and Lossy Networks
[I-D.ietf-6lowpan-hc].
Resulting addressing can be achieved by combining the 40bit RFPI of
the FP and the 20bit TPUI of the PP. A mapping scheme to compute the
IID must be developed.
7. IPv6 Link Local Address
How do we form the IPv6 Link Local Address, or can this be obtained
from the IID using SLAC ?
The IPv6 LLA [RFC4291] for a DECT ULE device is formed by appending
the XXXX to form the 128 bit LLA. this is done by appending the
prefix FE80::/64 to the IPv6 address found through SLAAC.
All packets transferred between the ULE FP and PP are addressed on
Mariager & Petersen Expires May 3, 2012 [Page 7]
Internet-Draft IPv6 over DECT ULE October 2011
MAC layer by the 20bit TPUI.
8. Unicast and Multicast address mapping
It should be investigated how to support the LOWPAN_BC0 packets for
broadcast How do we utilize the DECT Broadcast features for multicast
?
DECT FP has MAC features to allow broadcast or multicast small amount
of data (max 27 bytes). However ULE PP entering into long sleep
period cannot receive these packets reliably. Other methods for
emulating broadcast/multicast could be considered, such as queuing
these packets until a ULE PP wakes up.
9. Header Compression
Compression Format for IPv6 Datagrams in Low Power and Lossy Networks
(6LoWPAN) [I-D.ietf-6lowpan-hc].
In [RFC4944] different types of frame formats and related headers
have been defined to support fragmentation and mesh addressing.
In ULE context LoWPAN_IPHC compressed IPv6 header would be used by
default. Support for fragmentation and mesh headers can be added if
required (if not provided by the ULE DLC layer).
10. Security Considerations
The transmission of speech over DECT will be based on the DSAA2 and
DSC2 work being developed by the DF Security group / ETSI TC DECT and
the ETSI SAGE Security expert group. However, these security
mechanisms may not be fully compatible to the connection-less nature
of DECT ULE, hence new mechanisms must be investigated.
Additional security such as per-message authentication through CBC-
MAC are currently being defined in the ETSI TC-DECT ULE group. It is
expected that the DECT ULE DLC layer will implement per-message
authentication and encryption to optionally provide security on top
of the mandatory and additional security mechanicms defined in ETSI
TC-DECT.
The underlying algorithm for providing authentication and encryption
is based on AES128. Individual key for each ULE PP are generated
during the binding procedure. Encryption keys are renewed regularly.
DECT ULE does not use any shared encryption key.
Mariager & Petersen Expires May 3, 2012 [Page 8]
Internet-Draft IPv6 over DECT ULE October 2011
11. Considerations
PP roaming between FP is not considered in this draft. The use of
repeater functionality is not considered in this draft
12. Acknowledgements
13. IANA Considerations
14. Security Considerations
15. Normative References
[ETSI EN300 175 (1-7)]
"".
[ETSI TS102 827]
"".
[I-D.ietf-6lowpan-hc]
"".
[I-D.ietf-6lowpan-nd]
"".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] "".
[RFC4944] "".
Authors' Addresses
Peter B. Mariager (editor)
RTX A/S
Email: pm@rtx.dk
Mariager & Petersen Expires May 3, 2012 [Page 9]
Internet-Draft IPv6 over DECT ULE October 2011
Jens T. Petersen
RTX A/S
Email: jtp@rtx.dk
Mariager & Petersen Expires May 3, 2012 [Page 10]